RFC(F) 7617

From RFC.Wiki
Jump to: navigation, search

Groupe de travail sur l'ingénierie Internet (IETF)             J. Reschke
Demande de commentaires: 7617                                  greenbytes
Obsolètes: 2617                                            septembre 2015
Catégorie: Standards Track
ISSN: 2070-1721

             Le schéma d'authentification HTTP «de base»

Abstrait

   Ce document définit le protocole HTTP (Hypertext Transfer Protocol) «de base»
   schéma d'authentification, qui transmet les informations d'identification en tant qu'ID utilisateur /
   paires de mots de passe, codées à l'aide de Base64.

Statut de ce mémo

   Il s'agit d'un document Internet Standards Track.

   Ce document est un produit de l'Internet Engineering Task Force
   (IETF). Il représente le consensus de la communauté IETF. Il a
   a reçu un examen public et a été approuvé pour publication par le
   Groupe directeur de l'ingénierie Internet (IESG). Plus d'informations sur
   Les normes Internet sont disponibles dans la section 2 de la RFC 5741 .

   Informations sur l'état actuel de ce document, tout errata,
   et comment fournir des commentaires à ce sujet
   http://www.rfc-editor.org/info/rfc7617 .

Copyright

   Copyright (c) 2015 IETF Trust et les personnes identifiées comme
   auteurs de documents. Tous les droits sont réservés.

   Ce document est soumis au BCP 78 et aux mentions légales de l'IETF Trust.
   Dispositions relatives aux documents de l'IETF
   ( http://trustee.ietf.org/license-info ) en vigueur à la date de
   publication de ce document. Veuillez consulter ces documents
   soigneusement, car ils décrivent vos droits et restrictions en ce qui concerne
   à ce document. Les composants de code extraits de ce document doivent
   inclure le texte de la licence BSD simplifiée comme décrit dans la section 4.e de
   les dispositions légales de Trust et sont fournis sans garantie
   décrit dans la licence BSD simplifiée.

   Ce document peut contenir des éléments des documents de l'IETF ou de l'IETF
   Contributions publiées ou rendues publiques avant novembre
   10, 2008. La ou les personnes contrôlant le droit d'auteur sur certains de ces
   matériel peut ne pas avoir accordé à l'IETF Trust le droit d'autoriser
   modifications de ce matériel en dehors du processus de normalisation de l'IETF.
   Sans obtenir une licence adéquate de la ou des personnes contrôlant
   le droit d'auteur sur ces documents, ce document ne peut pas être modifié
   en dehors du processus de normalisation de l'IETF, et les travaux dérivés de celui-ci peuvent
   ne pas être créé en dehors du processus de normalisation de l'IETF, sauf pour formater
   pour publication sous forme de RFC ou pour le traduire dans d'autres langues
   que l'anglais.

Table des matières

   1 . Introduction . . . . . . . . . . . . . . . . . . . . . . . .    3
     1.1 . Terminologie et notation. . . . . . . . . . . . . . . .    3
   2 . Le schéma d'authentification «de base». . . . . . . . . . . . . .    3
     2.1 . Le paramètre d'authentification «charset». . . . . . . . . . . . . . . .    5
     2.2 . Réutilisation des informations d'identification. . . . . . . . . . . . . . . . . . .    7
   3 . Considérations d'internationalisation. . . . . . . . . . . . .    8
   4 . Considérations de sécurité. . . . . . . . . . . . . . . . . . .    8
   5 . Considérations IANA. . . . . . . . . . . . . . . . . . . . .    9
   6 . Références . . . . . . . . . . . . . . . . . . . . . . . . .   10
     6.1 . Références normatives . . . . . . . . . . . . . . . . . .   10
     6.2 . Références informatives. . . . . . . . . . . . . . . . .   11
   Annexe A . Modifications de la RFC 2617   . . . . . . . . . . . . . . .   13
   Annexe B . Considérations de déploiement pour le «jeu de caractères»
                Paramètre. . . . . . . . . . . . . . . . . . . . .  13
     B.1 . Agents utilisateurs. . . . . . . . . . . . . . . . . . . . . . .  13
     B.2 . Les serveurs . . . . . . . . . . . . . . . . . . . . . . . . .  13
     B.3 . Pourquoi ne pas simplement basculer l'encodage par défaut sur UTF-8? . .  14
   Remerciements. . . . . . . . . . . . . . . . . . . . . . . .  14
   Adresse de l'auteur. . . . . . . . . . . . . . . . . . . . . . . .  15

1 . introduction

   Ce document définit le protocole HTTP (Hypertext Transfer Protocol) «de base»
   schéma d'authentification, qui transmet les informations d'identification en tant qu'ID utilisateur /
   paires de mots de passe, codées à l'aide de Base64 (les schémas d'authentification HTTP sont
   défini dans [ RFC7235 ]).

   Ce schéma n'est pas considéré comme une méthode sécurisée d'utilisation
   authentification, sauf si elle est utilisée en conjonction avec une sécurité externe
   système comme TLS (Transport Layer Security, [ RFC5246 ]), comme
   l'ID utilisateur et le mot de passe sont transmis sur le réseau en texte clair.

   Le schéma "de base" a été précédemment défini dans la section 2 de [RFC2617] .
   Ce document met à jour la définition et aborde également
   les problèmes d'internationalisation en introduisant le «charset»
   paramètre d'authentification ( section 2.1 ).

   D'autres documents mettant à jour la RFC 2617 sont "Hypertext Transfer Protocol"
   (HTTP / 1.1): Authentification "([ RFC7235 ], définissant l'authentification
   framework), "HTTP Digest Access Authentication" ([ RFC7616 ], mise à jour
   la définition du schéma d'authentification "Digest"), et "HTTP
   En-tête de réponse Authentication-Info et Proxy-Authentication-Info
   Fields "([ RFC7615 ]). Pris ensemble, ces quatre documents obsolètes
    RFC 2617 .

1.1 . Terminologie et notation

   Les mots clés "DOIT", "NE DOIT PAS", "OBLIGATOIRE", "DOIT", "NE DOIT PAS",
   "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDÉ", "MAI" et "FACULTATIF" dans ce
   document doivent être interprétés comme décrit dans [ RFC2119 ].

   Les termes «espace de protection» et «domaine» sont définis à la section 2.2
   de [RFC7235] .

   Les termes "répertoire (de caractères)" et "schéma de codage de caractères"
   sont définis dans la section 2 de la [RFC6365] .

2 . Le schéma d'authentification «de base»

   The Basic authentication scheme is based on the model that the client
   doit s'authentifier avec un identifiant et un mot de passe pour chacun
   espace de protection ("royaume"). La valeur de domaine est une chaîne de forme libre
   qui ne peut être comparé que pour l'égalité avec d'autres royaumes sur ce
   serveur. Le serveur ne traitera la demande que s'il peut valider
   l'ID utilisateur et le mot de passe de l'espace de protection s'appliquant au
   ressource demandée.

   Le schéma d'authentification de base utilise le cadre d'authentification
   comme suit.

   Dans les défis:

   o Le nom du schéma est "Basic".

   o Le paramètre d'authentification «royaume» est OBLIGATOIRE ( [RFC7235],
      Section 2.2 ).

   o Le paramètre d'authentification 'charset' est FACULTATIF (voir
      Section 2.1 ).

   o Aucun autre paramètre d'authentification n'est défini - inconnu
      les paramètres DOIVENT être ignorés par les destinataires, et de nouveaux paramètres peuvent
      ne peut être défini qu'en révisant cette spécification.

   Voir également la section 4.1 de la [RFC7235] , qui traite de la complexité de
   analyser correctement les défis.

   Notez que les noms de schéma et de paramètre correspondent à la casse.
   insensiblement.

   Pour les informations d'identification, la syntaxe "token68" définie à la section 2.1 de
   [RFC7235] est utilisé. La valeur est calculée sur la base de l'ID utilisateur et
   mot de passe tel que défini ci-dessous.

   Sur réception d'une demande d'URI dans l'espace de protection qui
   manque d'informations d'identification, le serveur peut répondre avec un défi en utilisant le
   Code d'état 401 (non autorisé) ( [RFC7235], section 3.1 ) et le
   Champ d'en-tête WWW-Authenticate ( [RFC7235], section 4.1 ).

   Par exemple:

      HTTP / 1.1 401 non autorisé
      Date: lun.04 févr.2014 16:50:53 GMT
      WWW-Authenticate: royaume de base = "WallyWorld"

   où "WallyWorld" est la chaîne attribuée par le serveur pour identifier
   l'espace de protection.

   Un proxy peut répondre avec un défi similaire en utilisant le 407 (Proxy
   Authentification requise) code d'état ( [RFC7235], section 3.2 ) et le
   Champ d'en-tête Proxy-Authenticate ( [RFC7235], Section 4.3 ).

   Pour recevoir l'autorisation, le client

   1. obtient l'identifiant et le mot de passe de l'utilisateur,

   2. construit le passe utilisateur en concaténant l'ID utilisateur, un seul
       deux points (":") et le mot de passe,

   3. code la passe utilisateur en une séquence d'octets (voir ci-dessous pour
       discussion des schémas de codage de caractères),

   4. et obtient les informations d'identification de base en codant cette séquence d'octets
       en utilisant Base64 ( [RFC4648], Section 4 ) dans une séquence de US-ASCII
       caractères ([ RFC0020 ]).

   La définition d'origine de ce schéma d'authentification n'a pas pu
   spécifier le schéma de codage de caractères utilisé pour convertir le passe utilisateur
   dans une séquence d'octets. En pratique, la plupart des implémentations ont choisi
   soit un codage spécifique aux paramètres régionaux tel que ISO-8859-1 ([ ISO-8859-1 ]),
   ou UTF-8 ([ RFC3629 ]). Pour des raisons de compatibilité ascendante, cette
   spécification continue de laisser l'encodage par défaut non défini, car
   tant qu'il est compatible avec US-ASCII (mappage de tout US-ASCII
   caractère à un seul octet correspondant au code de caractère US-ASCII).

   L'ID utilisateur et le mot de passe NE DOIVENT PAS contenir de caractères de contrôle (voir
   "CTL" dans l' appendice B.1 de la [RFC5234] ).

   En outre, un ID utilisateur contenant un caractère deux-points n'est pas valide, car
   le premier deux-points dans une chaîne de passe utilisateur sépare l'ID utilisateur et le mot de passe
   l'un de l'autre; le texte après le premier deux-points fait partie du mot de passe.
   Les ID utilisateur contenant des deux-points ne peuvent pas être codés dans des chaînes de passe utilisateur.

   Notez que de nombreux agents utilisateurs produisent des chaînes de passe utilisateur sans vérifier
   que les ID utilisateur fournis par les utilisateurs ne contiennent pas de deux-points; destinataires
   traitera alors une partie de l'entrée du nom d'utilisateur comme faisant partie du mot de passe.

   Si l'agent utilisateur souhaite envoyer l'ID utilisateur "Aladdin" et le mot de passe
   "sésame ouvert", il utiliserait le champ d'en-tête suivant:

      Autorisation: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ ==

2.1 . Le paramètre d'authentification `` charset ''

   Dans les défis, les serveurs peuvent utiliser le paramètre d'authentification «charset»
   pour indiquer le schéma de codage de caractères qu'ils attendent de l'agent utilisateur
   à utiliser lors de la génération de "user-pass" (une séquence d'octets). Cette
   l'information est purement consultative.

   La seule valeur autorisée est "UTF-8"; il doit être apparié cas-
   de manière insensible (voir [RFC2978], section 2.3 ). Il indique que le
   le serveur s'attend à ce que les données de caractères soient converties en Unicode
   Formulaire de normalisation C ("NFC"; voir la section 3 de la [RFC5198] ) et à
   codé en octets à l'aide du schéma de codage de caractères UTF-8
   ([ RFC3629 ]).

   Pour l'ID utilisateur, les destinataires DOIVENT prendre en charge tous les caractères définis dans
   le profil "UsernameCasePreserved" défini à la section 3.3 de
   [RFC7613] , à l'exception du caractère deux-points (":").

   Pour le mot de passe, les destinataires DOIVENT prendre en charge tous les caractères définis dans
   le profil "OpaqueString" défini dans la section 4.2 de la [RFC7613] .

   D'autres valeurs sont réservées pour une utilisation future.

      Remarque: le `` jeu de caractères '' est uniquement défini sur les défis, comme Basic
      l'authentification utilise un seul jeton pour les informations d'identification ('token68'
      syntaxe); ainsi, la syntaxe des informations d'identification n'est pas extensible.

      Remarque: Le nom «charset» a été choisi par souci de cohérence avec
      Section 2.1.1 de la [RFC2831] . Un meilleur nom aurait été
      'accept-charset', car il ne s'agit pas du message dans lequel il apparaît,
      mais l'attente du serveur.

   Dans l'exemple ci-dessous, le serveur demande une authentification dans le
   domaine "foo", en utilisant l'authentification de base, avec une préférence pour le
   Schéma de codage de caractères UTF-8:

      WWW-Authenticate: royaume de base = "foo", charset = "UTF-8"

   Notez que la valeur du paramètre peut être un jeton ou un guillemet
   chaîne; dans ce cas, le serveur a choisi d'utiliser la chaîne entre guillemets
   notation.

   Le nom de l'utilisateur est "test" et le mot de passe est la chaîne "123"
   suivi du caractère Unicode U + 00A3 (POUND SIGN). En utilisant le
   schéma de codage de caractères UTF-8, la passe utilisateur devient:

      't' 'e' 's' 't' ':' '1' '2' '3' livre
      74 65 73 74 3A 31 32 33 C2 A3

   Le codage de cette séquence d'octets en Base64 ( [RFC4648], Section 4 ) donne:

      dGVzdDoxMjPCow ==

   Ainsi, le champ d'en-tête Autorisation serait:

      Autorisation: Basic dGVzdDoxMjPCow ==

   Ou, pour l'authentification proxy:

      Autorisation proxy: dGVzdDoxMjPCow de base ==

2.2 . Réutilisation des informations d'identification

   Étant donné l'URI absolu ( [RFC3986], section 4.3 ) d'un authentifié
   demande, la portée d'authentification de cette demande est obtenue par
   supprimer tous les caractères après la dernière barre oblique ("/") du
   composant de chemin ("hier_part"; voir [RFC3986], Section 3 ). Un client
   DEVRAIT supposer que les ressources identifiées par les URI avec une correspondance de préfixe
   de la portée d'authentification se trouvent également dans l'espace de protection
   spécifié par la valeur de domaine de cette demande authentifiée.

   Un client PEUT envoyer à titre préventif l'en-tête d'autorisation correspondant
   champ avec des demandes de ressources dans cet espace sans réception de
   un autre défi du serveur. De même, lorsqu'un client envoie un
   demande à un proxy, il PEUT réutiliser un identifiant et un mot de passe dans le proxy.
   Champ d'en-tête d'autorisation sans recevoir d'autre défi de la part de
   le serveur proxy.

   Par exemple, étant donné une demande authentifiée pour:

      http://example.com/docs/index.html

   les demandes adressées aux URI ci-dessous pourraient utiliser les informations d'identification connues:

      http://example.com/docs/
      http://example.com/docs/test.doc
      http://example.com/docs/?page=1

   tandis que les URI

      http://example.com/other/
      https://example.com/docs/

   serait considéré comme étant en dehors de la portée de l'authentification.

   Notez qu'un URI peut faire partie de plusieurs étendues d'authentification (telles que
   comme "http://example.com/" et "http://example.com/docs/"). Cette
   la spécification ne définit pas lesquels de ceux-ci doivent être traités avec
   priorité plus élevée.

3 . Considérations d'internationalisation

   ID utilisateur ou mots de passe contenant des caractères en dehors de l'US-ASCII
   le répertoire de caractères entraînera des problèmes d'interopérabilité, à moins que les deux
   les partenaires de communication conviennent du schéma de codage des caractères
   être utilisé. Les serveurs peuvent utiliser le nouveau paramètre 'charset' ( Section 2.1 )
   pour indiquer une préférence pour "UTF-8", augmentant la probabilité que
   les clients passeront à cet encodage.

   Le paramètre «realm» contient des données qui peuvent être considérées comme textuelles;
   cependant, la [ RFC7235 ] ne définit pas un moyen de transporter de manière fiable des
   Caractères US-ASCII. Il s'agit d'un problème connu qui devrait être
   traités dans une révision de cette spécification.

4 . Considérations de sécurité

   Le schéma d'authentification de base n'est pas une méthode sécurisée d'utilisateur
   l'authentification, ni ne protège en aucune façon l'entité, qui est
   transmis en texte clair sur le réseau physique utilisé comme
   transporteur. HTTP n'empêche pas l'ajout d'améliorations (telles que
   pour utiliser des mots de passe à usage unique) à l'authentification de base.

   La faille la plus grave de l'authentification de base est qu'elle entraîne
   la transmission en texte clair du mot de passe de l'utilisateur sur le
   réseau. De nombreux autres schémas d'authentification résolvent ce problème.

   Parce que l'authentification de base implique la transmission en texte clair de
   mots de passe, il NE DEVRAIT PAS être utilisé (sans améliorations telles que HTTPS
   [ RFC2818 ]) pour protéger les informations sensibles ou précieuses.

   Une utilisation courante de l'authentification de base est à des fins d'identification
   - obliger l'utilisateur à fournir un identifiant et un mot de passe pour
   identification, par exemple, pour recueillir une utilisation précise
   statistiques sur un serveur. Lorsqu'il est utilisé de cette manière, il est tentant de
   pense qu'il n'y a pas de danger dans son utilisation si l'accès illicite à la
   les documents protégés ne sont pas une préoccupation majeure. Ceci n'est correct que si
   le serveur délivre à la fois l'ID utilisateur et le mot de passe aux utilisateurs et, dans
   en particulier, ne permet pas à l'utilisateur de choisir son propre
   mot de passe. Le danger vient du fait que les utilisateurs naïfs réutilisent fréquemment un
   mot de passe unique pour éviter la tâche de maintenir plusieurs mots de passe.

   Si un serveur permet aux utilisateurs de sélectionner leurs propres mots de passe, le
   la menace est non seulement l'accès non autorisé aux documents sur le serveur, mais
   également un accès non autorisé à d'autres ressources sur d'autres systèmes qui
   l'utilisateur protège avec le même mot de passe. En outre, dans
   base de données de mots de passe du serveur, la plupart des mots de passe peuvent également être ceux des utilisateurs
   mots de passe pour d'autres sites. Le propriétaire ou l'administrateur d'un tel
   système pourrait donc exposer tous les utilisateurs du système au risque de

   accès non autorisé à tous ces autres sites si ces informations sont
   pas maintenu de façon sécurisée. Cela soulève à la fois la sécurité et
   problèmes de confidentialité ([ RFC6973 ]). Si le même ID utilisateur et le même mot de passe
   est utilisée pour accéder à d'autres comptes, comme un e-mail ou
   compte de portail de santé, des informations personnelles pourraient être exposées.

   L'authentification de base est également vulnérable à l'usurpation d'identité par contrefaçon
   les serveurs. Si un utilisateur peut être amené à croire qu'il se connecte à un
   hôte contenant des informations protégées par l'authentification de base lorsque,
   en fait, elle se connecte à un serveur ou une passerelle hostile, puis
   l'attaquant peut demander un mot de passe, le stocker pour une utilisation ultérieure et simuler un
   Erreur. Les implémenteurs de serveurs doivent se prémunir contre ce type de
   la contrefaçon; en particulier, les composants logiciels qui peuvent prendre le relais
   le contrôle du cadrage du message sur une connexion existante doit être
   utilisé avec soin ou pas du tout (par exemple: NPH ("Non-Parsed Header")
   comme décrit dans la section 5 de la [RFC3875] ).

   Les serveurs et les proxys implémentant l'authentification de base doivent stocker
   les mots de passe des utilisateurs sous une forme quelconque afin d'authentifier une demande.
   Ces mots de passe doivent être stockés de manière à ce qu'une fuite du
   les données de mot de passe ne les rendent pas facilement récupérables. C'est
   particulièrement important lorsque les utilisateurs sont autorisés à définir leur propre
   les mots de passe, car les utilisateurs sont connus pour choisir des mots de passe
   réutilisez-les dans les domaines d'authentification. Bien qu’une discussion approfondie
   de bonnes techniques de hachage de mot de passe dépassent le cadre de cette
   document, les opérateurs de serveurs doivent s'efforcer de minimiser les risques
   à leurs utilisateurs en cas de fuite de données de mot de passe. Par exemple,
   les serveurs doivent éviter de stocker les mots de passe des utilisateurs en texte brut ou en tant que
   résumés non salés. Pour plus de discussion sur le hachage de mot de passe moderne
   techniques, voir le "Concours de hachage de mot de passe"
   (< https://password-hashing.net >).

   L'utilisation du schéma de codage de caractères UTF-8 et de la normalisation
   introduit des considérations de sécurité supplémentaires; voir la section 10 de
   [RFC3629] et la section 6 de [RFC5198] pour plus d'informations.

5 . Considérations IANA

   L'IANA maintient l'authentification "Hypertext Transfer Protocol (HTTP)
   Scheme Registry "([ RFC7235 ]) à < http://www.iana.org/assignments/
   http-authschemes >.

   L'entrée pour le schéma d'authentification "de base" a été mise à jour pour
   référencer cette spécification.

6 . Références

6.1 . Références normatives

   [ RFC20 ] Cerf, V., "Format ASCII pour l'échange de réseaux", STD 80,
               RFC 20 , DOI 10.17487 / RFC0020, octobre 1969,
              < http://www.rfc-editor.org/info/rfc20 >.

   [ RFC2119 ] Bradner, S., "Mots clés à utiliser dans les RFC pour indiquer
              Niveaux d'exigence ", BCP 14 , RFC 2119 ,
              DOI 10.17487 / RFC2119, mars 1997,
              < http://www.rfc-editor.org/info/rfc2119 >.

   [ RFC2978 ] Freed, N. et J. Postel, "IANA Charset Registration
              Procédures ", BCP 19 , RFC 2978 , DOI 10.17487 / RFC2978,
              Octobre 2000, < http://www.rfc-editor.org/info/rfc2978 >.

   [ RFC3629 ] Yergeau, F., "UTF-8, un format de transformation de l'ISO
              10646 ", STD 63, RFC 3629 , DOI 10.17487 / RFC3629, novembre
              2003, < http://www.rfc-editor.org/info/rfc3629 >.

   [ RFC3986 ] Berners-Lee, T., Fielding, R. et L. Masinter, "Uniform
              Identifiant de ressource (URI): syntaxe générique ", STD 66,
              RFC 3986 , DOI 10.17487 / RFC3986, janvier 2005,
              < http://www.rfc-editor.org/info/rfc3986 >.

   [ RFC4648 ] Josefsson, S., "Les données Base16, Base32 et Base64
              Encodings ", RFC 4648 , DOI 10.17487 / RFC4648, octobre 2006,
              < http://www.rfc-editor.org/info/rfc4648 >.

   [ RFC5198 ] Klensin, J. et M. Padlipsky, "Format Unicode pour réseau
              Interchange ", RFC 5198 , DOI 10.17487 / RFC5198, mars 2008,
              < http://www.rfc-editor.org/info/rfc5198 >.

   [ RFC5234 ] Crocker, D., Ed. et P. Overell, "BNF augmenté pour la syntaxe
              Spécifications: ABNF ", STD 68, RFC 5234 ,
              DOI 10.17487 / RFC5234, janvier 2008,
              < http://www.rfc-editor.org/info/rfc5234 >.

   [ RFC6365 ] Hoffman, P. et J. Klensin, "Terminologie utilisée dans
              Internationalisation dans l'IETF ", BCP 166 , RFC 6365 ,
              DOI 10.17487 / RFC6365, septembre 2011,
              < http://www.rfc-editor.org/info/rfc6365 >.

   [ RFC7235 ] Fielding, R., Ed. et J. Reschke, Ed., "Hypertext Transfer
              Protocole (HTTP / 1.1): Authentification ", RFC 7235 ,
              DOI 10.17487 / RFC7235, juin 2014,
              < http://www.rfc-editor.org/info/rfc7235 >.

   [ RFC7613 ] Saint-Andre, P. et A. Melnikov, "Préparation,
              Application et comparaison des chaînes internationalisées
              Représentant les noms d'utilisateur et les mots de passe ", RFC 7613 ,
              DOI 10.17487 / RFC7613, août 2015,
              < http://www.rfc-editor.org/info/rfc7613 >.

6.2 . Références informatives

   [ ISO-8859-1 ]
              Organisation internationale de normalisation,
              "Technologies de l'information - Graphique codé sur un octet 8 bits
              jeux de caractères - Partie 1: Alphabet latin n ° 1 ", ISO / CEI
              8859-1: 1998, 1998.

   [ RFC2617 ] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
              Leach, P., Luotonen, A. et L. Stewart, "HTTP
              Authentification: Authentification d'accès de base et Digest ",
              RFC 2617 , DOI 10.17487 / RFC2617, juin 1999,
              < http://www.rfc-editor.org/info/rfc2617 >.

   [ RFC2818 ] Rescorla, E., "HTTP Over TLS", RFC 2818 ,
              DOI 10.17487 / RFC2818, mai 2000,
              < http://www.rfc-editor.org/info/rfc2818 >.

   [ RFC2831 ] Leach, P. et C. Newman, "Utilisation de l'authentification Digest comme
              Mécanisme SASL ", RFC 2831 , DOI 10.17487 / RFC2831, mai 2000,
              < http://www.rfc-editor.org/info/rfc2831 >.

   [ RFC3875 ] Robinson, D. et K. Coar, "L'interface de passerelle commune
              (CGI) Version 1.1 ", RFC 3875 , DOI 10.17487 / RFC3875,
              Octobre 2004, < http://www.rfc-editor.org/info/rfc3875 >.

   [ RFC5246 ] Dierks, T. et E. Rescorla, «The Transport Layer Security
              (TLS) Protocol Version 1.2 ", RFC 5246 ,
              DOI 10.17487 / RFC5246, août 2008,
              < http://www.rfc-editor.org/info/rfc5246 >.

   [ RFC6973 ] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
              Morris, J., Hansen, M. et R. Smith, "Confidentialité
              Considérations pour les protocoles Internet ", RFC 6973 ,
              DOI 10.17487 / RFC6973, juillet 2013,
              < http://www.rfc-editor.org/info/rfc6973 >.

   [ RFC7231 ] Fielding, R., Ed. et J. Reschke, Ed., "Hypertext Transfer
              Protocole (HTTP / 1.1): sémantique et contenu ", RFC 7231 ,
              DOI 10.17487 / RFC7231, juin 2014,
              < http://www.rfc-editor.org/info/rfc7231 >.

   [ RFC7615 ] Reschke, J., "HTTP Authentication-Info and Proxy-
              Champs d'en-tête de réponse Authentication-Info ", RFC 7615 ,
              DOI 10.17487 / RFC7615, septembre 2015,
              < http://www.rfc-editor.org/info/rfc7615 >.

   [ RFC7616 ] Shekh-Yusef, R., Ed., Ahrens, D. et S. Bremer, "HTTP
              Authentification d'accès au résumé ", RFC 7616 ,
              DOI 10.17487 / RFC7616, septembre 2015,
              < http://www.rfc-editor.org/info/rfc7616 >.

Annexe A . Modifications de la RFC 2617

   La définition du régime a été réécrite pour être cohérente avec la nouvelle
   spécifications telles que [ RFC7235 ].

   Le nouveau paramètre d'authentification «charset» a été ajouté. C'est
   purement consultatif, les implémentations existantes n'ont donc pas besoin de changer,
   à moins qu'ils ne souhaitent profiter des informations supplémentaires
   n'était pas disponible auparavant.

Annexe B . Considérations de déploiement pour le paramètre «charset»

B.1 . Agents utilisateurs

   Les agents utilisateurs n'implémentant pas «charset» continueront de fonctionner comme
   avant, en ignorant le nouveau paramètre.

   Agents utilisateurs qui utilisent déjà par défaut l'implémentation de codage UTF-8
   «charset» par définition.

   Les autres agents utilisateurs peuvent conserver leur comportement par défaut et passer à UTF-8
   en voyant le nouveau paramètre.

B.2 . Les serveurs

   Les serveurs qui ne prennent pas en charge les caractères non US-ASCII dans les informations d'identification
   ne nécessite aucune modification pour prendre en charge «charset».

   Serveurs qui doivent prendre en charge les caractères non US-ASCII, mais ne peuvent pas utiliser
   le schéma de codage des caractères UTF-8 ne sera pas affecté; elles vont
   continuer à fonctionner aussi bien ou aussi mal qu'auparavant.

   Enfin, les serveurs qui doivent prendre en charge les caractères non US-ASCII et peuvent
   utiliser le schéma de codage de caractères UTF-8 peut s'inscrire en spécifiant le
   paramètre «charset» dans le défi d'authentification. Clients qui le font
   comprendre le paramètre «charset» va alors commencer à utiliser UTF-8,
   tandis que d'autres clients continueront d'envoyer des informations d'identification dans leur
   encodage par défaut, informations d'identification brisées ou aucune information d'identification.
   Jusqu'à ce que tous les clients soient mis à niveau pour prendre en charge UTF-8, les serveurs sont susceptibles
   pour voir les encodages UTF-8 et "hérités" dans les requêtes. Quand
   traitement comme UTF-8 échoue (en raison d'un échec de décodage en UTF-8 ou d'un
   non concordance de l’ID utilisateur / mot de passe), un serveur peut essayer de
   codage hérité précédemment pris en charge afin de prendre en charge ces
   clients hérités. Notez que des tentatives implicites doivent être effectuées
   soigneusement; par exemple, certains sous-systèmes peuvent détecter des connexions répétées
   les échecs et les traiter comme une attaque potentielle de devinettes.

B.3 . Pourquoi ne pas simplement basculer l'encodage par défaut sur UTF-8?

   Il y a des sites utilisés aujourd'hui qui utilisent par défaut un caractère local
   schéma de codage, tel que ISO-8859-1 ([ ISO-8859-1 ]), et attendez l'utilisateur
   agents d'utiliser cet encodage. L'authentification sur ces sites s'arrêtera
   fonctionne si l'agent utilisateur passe à un autre codage, tel que
   UTF-8.

   Notez que les sites peuvent même inspecter le champ d'en-tête User-Agent
   ( [RFC7231], section 5.5.3 ) pour décider quel schéma de codage de caractères
   attendre du client. Par conséquent, ils pourraient prendre en charge UTF-8 pour
   certains agents utilisateurs, mais par défaut à autre chose pour d'autres. Utilisateur
   les agents de ce dernier groupe devront continuer à faire ce qu'ils font
   aujourd'hui jusqu'à ce que la majorité de ces serveurs aient été mis à niveau vers
   utilisez toujours UTF-8.

Remerciements

   Cette spécification reprend la définition du HTTP "Basic"
   Schéma d'authentification, précédemment défini dans la RFC 2617 . Nous remercions John
   Franks, Phillip M. Hallam-Baker, Jeffery L. Hostetler, Scott
   D. Lawrence, Paul J. Leach, Ari Luotonen et Lawrence C. Stewart pour
   leurs travaux sur cette spécification, à partir desquels des quantités importantes de
   le texte a été emprunté. Voir la section 6 de la [RFC2617] pour plus
   remerciements.

   Le problème de l'internationalisation par rapport au personnage
   le schéma de codage utilisé pour la passe utilisateur a été signalé comme un bug de Mozilla
   en 2000 (voir
   < https://bugzilla.mozilla.org/show_bug.cgi?id=41489 > ainsi que le
   < https://bugzilla.mozilla.org/show_bug.cgi?id=656213 plus récent >).
   C'était l'idée d'Andrew Clover de l'aborder en utilisant un nouveau paramètre d'authentification.

   Nous remercions également les membres du groupe de travail HTTPAUTH et les autres
   examinateurs, à savoir Stephen Farrell, Roy Fielding, Daniel Kahn
   Gillmor, Tony Hansen, Bjoern Hoehrmann, Kari Hurtta, Amos Jeffries,
   Benjamin Kaduk, Michael Koeller, Eric Lawrence, Barry Leiba, James
   Manger, Alexey Melnikov, Kathleen Moriarty, Juergen Schoenwaelder,
   Yaron Sheffer, Meral Shirazipour, Michael Sweet et Martin Thomson
   pour des commentaires sur cette révision.

Adresse de l'auteur

   Julian F. Reschke
   greenbytes GmbH
   Hafenweg 16
   Muenster, NW 48155
   Allemagne

   Courriel: julian.reschke@greenbytes.de
   URI:    http://greenbytes.de/tech/webdav/