Groupe de travail Réseau	F. Miao, éd., Huawei Technologies
Request for Comments : 5425	Y. Ma, éd., Huawei Technologies
Catégorie : Sur la voie de la normalisation	J. Salowey, éd., Cisco Systems, Inc.
Traduction Claude Brière de L'Isle	mars 2009

Transposition de transport pour Syslog avec la sécurité de la couche transport (TLS)

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.

Le présent document peut contenir des matériaux provenant de documents de l’IETF ou de contributions à l’IETF publiées ou rendues disponibles au public avant le 10 novembre 2008. La ou les personnes qui ont le contrôle des droits de reproduction sur tout ou partie de ces matériaux peuvent n’avoir pas accordé à l’IETF Trust le droit de permettre des modifications de ces matériaux en dehors du processus de normalisation de l’IETF. Sans l’obtention d’une licence adéquate de la part de la ou des personnes qui ont le contrôle des droits de reproduction de ces matériaux, le présent document ne peut pas être modifié en dehors du processus de normalisation de l’IETF, et des travaux dérivés ne peuvent pas être créés en dehors du processus de normalisation de l’IETF, excepté pour le formater en vue de sa publication comme RFC ou pour le traduire dans une autre langue que l’anglais.

Résumé
Le présent document décrit l'utilisation de la sécurité de la couche transport (TLS, Transport Layer Security) pour fournir une connexion sûre au transport de messages syslog. Il décrit les menaces sur la sécurité pour syslog et comment TLS peut être utilisée pour contrer de telles menaces.
Table des matières
1. Introduction	2
1.1 Terminologie	2
2. Exigences de sécurité pour Syslog	2
3. Utilisation de TLS pour sécuriser Syslog	3
4. Éléments du protocole	3
4.1 Allocation d'accès	3
4.2 Initiation	3
4.2.1 Authentification fondée sur le certificat	3
4.2.2 Empreintes digitales de certificat	4
4.2.3 Niveau cryptographique	4
4.3 Envoi de données	4
4.3.1 Longueur de message	5
4.4 Clôture	5
5. Politiques de sécurité	5
5.1 Autorisation d'entité d'extrémité fondée sur le certificat	5
5.2 Autorisation de nom de sujet	5
5.3 Envoyeur de transport non authentifié	6
5.4 Receveur de transport non authentifié	6
5.5 Receveur et envoyeur non authentifié de transport	6
6. Considérations sur la sécurité	6
6.1 Politiques d'authentification et d'autorisation	6
6.2 Validation du nom	7
6.3 Fiabilité	7
7. Considérations relatives à l’IANA	7
8. Remerciements	7
9. Références	7
9.1 Références normatives	7
9.2 Références pour information	8
Appendice A. Futures extensions	9
Adresse des auteurs	9

 	1.	Introduction

Le présent document décrit l'utilisation de la sécurité de la couche transport (TLS, Transport Layer Security) [RFC5246] pour fournir une connexion sûre pour le transport des messages syslog [RFC5424]. Ce document décrit les menaces sur la sécurité de syslog et comment TLS peut être utilisé pour contrer de telles menaces.

 	1.1	Terminologie
Les définitions suivantes sont utilisées dans ce document :

o	Un "générateur" génère un contenu syslog à porter dans un message.

o	Un "collecteur" rassemble les contenus syslog pour la suite de l'analyse.

o	Un "relais" transmet les messages, acceptant des messages provenant de générateurs ou d'autres relais, et les envoie aux collecteurs ou à d'autres relais.

o	Un "envoyeur de transport" passe les messages syslog à un protocole de transport spécifique.

o	Un "receveur de transport" prend les messages syslog provenant d'un protocole de transport spécifique.

o	Un "client TLS" est une application qui peut initier une connexion TLS en envoyant un "Client Hello" à un serveur.

o	Un "serveur TLS" est une application qui peut recevoir un "Client Hello" d'un client et répondre avec un "Serveur Hello".

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].

 	2.	Exigences de sécurité pour Syslog

Les messages Syslog peuvent transiter sur plusieurs bonds pour arriver au collecteur prévu. Certains réseaux intermédiaires peuvent n'être pas de confiance pour le générateur, relais, ou receveur parce que le réseau est dans un domaine de sécurité différent ou à un niveau de sécurité différent de celui du générateur, relais, ou collecteur. Un autre souci de sécurité est que le générateur, relais, ou receveur lui-même est dans un réseau non sûr.

Il y a plusieurs menaces qui doivent être traitées pour la sécurité de syslog. Les menaces principales sont :

o	Mascarade : un envoyeur de transport non autorisé peut envoyer des messages à un receveur de transport légitime, ou un receveur de transport non autorisé peut essayer de tromper un envoyeur de transport légitime en lui envoyant des messages syslog.

o	Modification : un attaquant entre l'envoyeur de transport et le receveur de transport peut modifier un message syslog en transit et transmettre ensuite le message au receveur du transport. Une telle modification peut faire que le receveur du transport comprend mal le message ou le fait se comporter de façon indésirable.

o	Divulgation : une entité non autorisée peut examiner le contenu des messages syslog, obtenant un accès non autorisé aux informations. Certaines données dans les messages syslog sont sensibles et peuvent être utiles à un attaquant, comme le mot de passe d'un administrateur ou utilisateur autorisé.

La menace secondaire est :

o	Modification du flux de messages : un attaquant peut supprimer un ou plusieurs messages syslog d'une série de messages, répéter un message, ou altérer la séquence de livraison. Le protocole syslog lui-même n'est pas fondé sur l'ordre des messages. Cependant, un événement dans un message syslog peut se rapporter sémantiquement à des événements dans d'autres messages, de sorte que l'ordre des messages peut être important pour comprendre une séquence d'événements.

Les menaces suivantes sont réputées être de moindre importance pour syslog, et ne sont pas traitées dans ce document :
o	déni de service
o 	analyse de trafic.

 	3.	Utilisation de TLS pour sécuriser Syslog

TLS peut être utilisé comme transport sûr pour contrer toutes les menaces principales pour syslog décrites ci-dessus :
o	Confidentialité pour contrer la divulgation du contenu du message.
o	Vérification de l'intégrité pour contrer les modifications d'un message bond par bond.
o	Authentification, du serveur, ou mutuelle, pour contrer les mascarades.

Note : ce transport sûr (c'est-à-dire, avec TLS) sécurise seulement le transport syslog bond par bond, et n'est pas concerné par le contenu des messages syslog. En particulier, l'identité authentifiée de l'envoyeur du transport (par exemple, le nom du sujet dans le certificat) n'est pas nécessairement en relation avec le champ HOSTNAME du message syslog. Quand l'authentification de l'origine du message syslog est exigée, la [RFC5848] peut être utilisée.

 	4.	Éléments du protocole
 	4.1	Allocation d'accès
Un envoyeur de transport syslog est toujours un client TLS et un receveur du transport est toujours un serveur TLS.

L'accès TCP 6514 a été alloué comme accès par défaut pour syslog sur TLS, comme défini dans ce document.

 	4.2	Initiation
L'envoyeur du transport devrait initier une connexion au receveur du transport et ensuite envoyer le Client Hello TLS pour commencer la prise de contact TLS. Quand la prise de contact TLS est terminée, l'envoyeur du transport PEUT alors envoyer le premier message syslog.

TLS utilise normalement des certificats [RFC5280] pour authentifier ses homologues. Les mises en œuvre DOIVENT prendre en charge TLS 1.2 [RFC5246] et il est EXIGÉ qu'elles prennent en charge la suite de chiffrement de mise en œuvre obligatoire, qui est TLS_RSA_WITH_AES_128_CBC_SHA. Le présent document est supposé s'appliquer aux futures versions de TLS, et dans ce cas, la suite de chiffrement de mise en œuvre obligatoire pour la version mise en œuvre DOIT être prise en charge.

 	4.2.1	Authentification fondée sur le certificat
L'envoyeur de transport syslog (client TLS) et le receveur de transport syslog (serveur TLS) DOIVENT tous deux mettre en œuvre l'authentification fondée sur le certificat. Cela consiste à valider le certificat et à vérifier que l'homologue a la clé privée correspondante. Cette dernière partie est effectuée par TLS. Pour assurer l'interopérabilité entre clients et serveurs, les méthodes suivantes de validation de certificat DEVRONT être mises en œuvre:

o	Validation du chemin de certification : l'homologue TLS est configuré avec une ou plusieurs ancres de confiance (normalement des certificats d'une autorité de certification (CA, certification authority) racine, ce qui lui permet de vérifier un lien entre le nom de sujet et la clé publique. Des contrôles de politique supplémentaires nécessaires pour autoriser l'envoyeur et le receveur de transport syslog (c'est-à-dire, vérifiant que le nom de sujet représente une partie autorisée) sont décrits à la Section 5. La validation du chemin de certification est effectuée comme défini dans la [RFC5280]. Cette méthode est utile lorsque il y a un déploiement d'infrastructure de clé publique (PKI, Public Key Infrastructure ).

o	Correspondance de certificat d'entité d'extrémité : l'envoyeur ou receveur de transport est configuré avec les informations nécessaires pour identifier les certificats valides d'entité d'extrémité de ses homologue autorisés. Les certificats d'entité d'extrémité peuvent être auto-signés, et aucune validation de chemin de certification n'est nécessaire. Les mises en œuvre DOIVENT prendre en charge les empreintes digitales de certificat du paragraphe 4.2.2 et PEUVENT permettre d'autres formats pour les certificats d'entité d'extrémité tels que le certificat codé en DER. Cette méthode fournit une solution de remplacement à une PKI qui est simple à déployer et conserve quand même un niveau raisonnable de sécurité.

Les mises en œuvre de receveur de transport et d'envoyeur de transport DOIVENT toutes deux fournir un moyen de générer une paire de clés et de certificat auto-signé dans le cas où une paire de clé et certificat n'est pas disponible par un autre mécanisme.

Le receveur de transport et l'envoyeur de transport DEVRAIENT fournir des mécanismes pour enregistrer le certificat d'entité d'extrémité pour le corréler avec les données envoyées ou reçues.

 	4.2.2	Empreintes digitales de certificat
Les mises en œuvre de client et de serveur DOIVENT rendre disponibles les empreintes digitales de certificat pour leur certificat par une interface de gestion. Les étiquettes pour les algorithmes sont prises de noms textuels des fonctions de hachage comme défini dans le registre de l'IANA "Noms textuels de fonction de hachage" allouées dans la [RFC4572].

Le mécanisme pour générer une empreinte digitale est de prendre le hachage du certificat codé en DER en utilisant un algorithme cryptographiquement fort, et de convertir le résultat en octets hexadécimaux séparés par un caractère deux-points, chacun représenté par deux caractères ASCII majuscules. Quand une valeur d'empreinte digitale est affichée ou configurée, l'empreinte digitale est ajoutée devant une étiquette ASCII qui identifie la fonction de hachage suivie par un caractère deux-points. Les mises en œuvre DOIVENT prendre en charge SHA-1 comme algorithme de hachage et utiliser l'étiquette ASCII "sha-1" pour identifier l'algorithme SHA-1. La longueur d'un hachage SHA-1 est de 20 octets et la longueur de l'empreinte digitale correspondante est de 65 caractères. Un exemple d'empreinte digitale de certificat est :

sha-1:E1:2D:53:2B:7C:6B:8A:29:A2:76:C8:64:36:0B:08:4B:7A:F1:9E:9D

Durant la validation, le hachage est extrait de l'empreinte digitale et comparé au hachage calculé sur le certificat reçu.

 	4.2.3	Niveau cryptographique
Les applications Syslog DEVRAIENT être mises en œuvre d'une manière qui permette aux administrateurs, selon leur politique locale, de choisir le niveau cryptographique et les options d'authentification qu'ils désirent.
'
TLS permet la reprise d'une session TLS antérieure ou l'utilisation d'une autre session active quand une nouvelle session est demandée, afin de s'épargner les coûts d'une autre prise de contact TLS complète. Les paramètres de sécurité de la session reprise sont réutilisés pour la session demandée. Les paramètres de sécurité DEVRAIENT être vérifiés à l'égard des exigences de sécurité de la session demandée pour s'assurer que la session reprise fournit une sécurité appropriée.

 	4.3	Envoi de données
Tous les messages syslog DOIVENT être envoyés comme des "données d'application" TLS. Il est possible que plusieurs messages syslog soient contenus dans un enregistrement TLS ou qu'un seul message syslog soit transféré dans plusieurs enregistrements TLS. Les données d'application sont définies avec l'expression d'ABNF [RFC5234] suivante :

APPLICATION-DATA = 1*SYSLOG-FRAME

SYSLOG-FRAME = MSG-LEN SP SYSLOG-MSG

MSG-LEN = NONZERO-DIGIT *DIGIT

SP = %d32

NONZERO-DIGIT = %d49-57

DIGIT = %d48 / NONZERO-DIGIT

SYSLOG-MSG est défini dans le protocole syslog [RFC5424].

 	4.3.1	Longueur de message
La longueur du message est le compte d'octets du SYSLOG-MSG dans le SYSLOG-FRAME. Un receveur de transport DOIT utiliser la longueur de message pour délimiter un message syslog. Il n'y a pas en soi de limite supérieure à la longueur d'un message. Cependant, afin d'établir une base pour l'interopérabilité, la présente spécification exige qu'un receveur de transport soit capable de traiter les messages d'une longueur jusqu'à et inclus 2048 octets. Le receveur de transports DEVRAIT être capable de traiter les messages de longueur jusqu'à et inclus 8192 octets.

 	4.4	Clôture
Un envoyeur de transport DOIT clore la connexion TLS associée si la connexion n'est pas supposée livrer d'autre message syslog. Il DOIT envoyer une alerte TLS close_notify avant de clore la connexion. Un envoyeur de transport (client TLS) PEUT choisir de ne pas attendre l'alerte close_notify du receveur de transport et simplement clore la connexion, générant donc une clôture incomplète chez le receveur de transport (serveur TLS). Une fois que le receveur de transport a obtenu un close_notify de l'envoyeur de transport, il DOIT répondre par un close_notify sauf si il a connaissance que la connexion a déjà été close par l'envoyeur de transport (par exemple, la clôture était indiquée par TCP).

Quand aucune donnée n'est reçue d'une connexion pendant longtemps (où l'application décide de ce que "longtemps" signifie) un receveur de transport PEUT clore la connexion. Le receveur de transport (serveur TLS) DOIT tenter d'initier un échange d'alertes close_notify avec l'envoyeur de transport avant de clore la connexion. Les receveurs de transport qui ne sont pas prêts à recevoir plus de données PEUVENT clore la connexion après l'envoi de l'alerte close_notify, générant donc une clôture incomplète chez l'envoyeur de transport.

 	5.	Politiques de sécurité

Des environnements différents ont des exigences de sécurité différentes et donc vont déployer des politiques de sécurité  différentes. Cette section discute certaines des politiques de sécurité qui peuvent être mises en œuvre par les receveurs de transport syslog et les envoyeurs de transport syslog. Les politiques de sécurité décrivent les exigences pour l'authentification et l'autorisation. La liste de politiques de cette section n'est pas exhaustive et d'autres politiques PEUVENT être mises en œuvre.

Si l'homologue ne satisfait pas les exigences de la politique de sécurité, la prise de contact TLS DOIT être interrompue avec l'alerte TLS appropriée.

 	5.1	Autorisation d'entité d'extrémité fondée sur le certificat
Dans le plus simple des cas, l'envoyeur et le receveur de transport sont configurés avec les informations nécessaires pour identifier les certificats valides d'entité d'extrémité de ses homologues autorisés.

Les mises en œuvre DOIVENT prendre en charge la spécification des homologues autorisés en utilisant les empreintes digitales de certificat, comme décrit aux paragraphes 4.2.1 et 4.2.2.

 	5.2	Autorisation de nom de sujet
Les mises en œuvre DOIVENT prendre en charge la validation de chemin de certification [RFC5280]. De plus, elles DOIVENT prendre en charge la spécification des homologues autorisés en utilisant des noms d'hôte configurés en local et en les confrontant au certificat comme suit :

o	Les mises en œuvre DOIVENT prendre en charge la confrontation du nom d'hôte configuré en local avec un dNSName dans le champ d'extension subjectAltName et DEVRAIT prendre en charge la vérification du nom par rapport à la portion nom commun du nom distinctif du sujet.

o	Le caractère générique '*' (ASCII 42) est permis dans le dNSName de l'extension subjectAltName (et dans le nom commun, si il est utilisé pour mémoriser le nom d'hôte) mais seulement comme étiquette DNS la plus à gauche (de moindre poids) dans cette valeur. Ce caractère générique correspond à toute étiquette DNS la plus à gauche dans le nom du serveur. C'est-à-dire, le sujet *.exemple.com correspond aux noms de serveur a.exemple.com et b.exemple.com, mais ne correspond pas à exemple.com ou à a.b.exemple.com. Les mises en œuvre DOIVENT prendre en charge les caractères génériques dans les certificats comme spécifié ci-dessus, mais PEUVENT fournir une option de configuration pour les désactiver.

o	Les noms configurés en local PEUVENT contenir le caractère générique pour correspondre à une gamme de valeurs. Les types de caractères génériques pris en charge PEUVENT être plus souples que ceux permis dans les noms de sujet, rendant possible la prise en charge de diverses politiques pour des environnements différents. Par exemple, une politique pourrait permettre une autorisation fondée sur une racine de confiance lorsque tous les accréditifs produits par une CA racine de confiance particulière sont autorisés.

o	Si le nom configuré en local est un nom de domaine internationalisé, les mises en œuvre conformes DOIVENT le convertir en format de codage compatible ASCII (ACE, ASCII Compatible Encoding) pour effectuer les comparaisons, comme spécifié dans la Section 7 de la [RFC5280].

o	Les mises en œuvre PEUVENT prendre en charge la confrontation d'une adresse IP configurée en local à une iPAddress mémorisée dans l'extension subjectAltName. Dans ce cas, l'adresse IP configurée en local est convertie en une chaîne d'octets comme spécifié dans la [RFC5280], paragraphe 4.2.1.6. Une correspondance se produit si cette chaîne d'octets est égale à la valeur de iPAddress dans l'extension subjectAltName.

 	5.3	Envoyeur de transport non authentifié
Dans certains environnements, l'authenticité des données syslog n'est pas importante ou est vérifiable par d'autres moyens, donc les receveurs de transport peuvent accepter des données de tout envoyeur de transport. Pour réaliser cela, le receveur de transport peut sauter l'authentification de l'envoyeur de transport (en ne demandant pas l'authentification du client dans TLS ou en acceptant tout certificat). Dans ce cas, le receveur de transport est authentifié et autorisé, cependant cette politique ne protège pas contre la menace de mascarade de l'envoyeur de transport décrite à la Section 2. L'utilisation de cette politique est généralement NON RECOMMANDÉE pour cette raison.

 	5.4	Receveur de transport non authentifié
Dans certains environnements, la confidentialité des données syslog n'est pas importante, de sorte que les messages sont envoyés à tout receveur de transport. Pour faire cela, l'envoyeur du transport peut sauter l'authentification du receveur de transport (en acceptant tous les certificats). Bien que cette politique authentifie et autorise l'envoyeur de transport, elle ne protège pas contre la menace de mascarade du receveur du transport décrite à la Section 2, laissant les données envoyées vulnérables à la divulgation et à la modification. L'utilisation de cette politique est généralement NON RECOMMANDÉE pour cette raison.

 	5.5	Receveur et envoyeur non authentifié de transport
Dans les environnements où la sécurité n'est pas du tout un problème, le receveur de transport et l'envoyeur de transport peuvent tous deux sauter l'authentification (comme décrit aux paragraphes 5.3 et 5.4). Cette politique ne protège pas contre les menaces décrites à la Section 2 et est donc NON RECOMMANDÉE.

 	6.	Considérations sur la sécurité

Cette Section décrit les considérations sur la sécurité qui s'ajoutent à celles de la [RFC5246].

 	6.1	Politiques d'authentification et d'autorisation
La Section 5 discute diverses politiques de sécurité qui peuvent être déployées. Les menaces de la Section 2 ne sont atténuées que si à la fois l'envoyeur de transport et le receveur de transport sont authentifiés et autorisés de façon appropriée, comme décrit aux paragraphes 5.1 et 5.2. Ce sont les configurations RECOMMANDÉES pour une politique par défaut.

Si le receveur de transport n'authentifie pas l'envoyeur du transport, il peut accepter des données d'un attaquant. Sauf si il a d'autres moyens d'authentifier la source des données, les données ne devraient pas être acceptées. Ceci est particulièrement important si les données syslog vont être utilisées pour détecter et réagir à des incidents de sécurité. Le receveur de transport peut aussi augmenter sa vulnérabilité à des attaques de déni de service, de consommation de ressources , et autres attaques, si il n'authentifie pas l'envoyeur du transport. À cause de la vulnérabilité accrue à l'attaque, ce type de configuration est NON RECOMMANDÉ.

Si l'envoyeur du transport n'authentifie pas le receveur du transport syslog, il peut alors envoyer des données à un attaquant.  Cela peut divulguer des données sensibles dans les informations enregistrées qui sont utiles à un attaquant, résultant en plus de compromissions dans le système. Si un envoyeur de transport fonctionne dans ce mode, les données envoyées DEVRAIENT être limitées aux données qui n'ont pas de valeur pour un attaquant. En pratique, ceci est très difficile à réaliser, donc ce type de configuration est NON RECOMMANDÉ.

L'authentification et l'autorisation précédentes sur les deux côtés permettent des types d'attaques par interposition, mascarade, et autres  qui peuvent complètement compromettre l'intégrité et la confidentialité des données. Ce type de configuration est NON RECOMMANDÉ.

 	6.2	Validation du nom
La politique d'autorisation du nom de sujet autorise le sujet dans le certificat par rapport à un nom configuré en local. Il n'est généralement pas approprié d'obtenir ce nom par d'autres moyens, comme une recherche du DNS, car cela introduit des vulnérabilités de sécurité supplémentaires.

 	6.3	Fiabilité
On devrait noter que le transport syslog spécifié dans ce document n'utilise pas d'accusé de réception de couche application.  TCP utilise des retransmissions pour fournir la protection contre certaines formes de pertes de données. Cependant, si la connexion TCP (ou la session TLS) est rompue pour une raison quelconque (ou close par le receveur de transport) l'envoyeur de transport syslog ne peut pas toujours savoir quels messages ont été livrés avec succès à l'application syslog à l'autre extrémité.

 	7.	Considérations relatives à l’IANA

L'IANA a alloué le numéro d'accès TCP 6514 dans la gamme des "Numéros d'accès enregistrés" avec le mot clé "syslog-tls". Cet accès va être l'accès par défaut pour syslog sur TLS, comme défini dans ce document.

 	8.	Remerciements

Les auteurs remercient Eric Rescorla, Rainer Gerhards, Tom Petch, Anton Okmianski, Balazs Scheidler, Bert Wijnen, Martin Schuette, Chris Lonvick, et les membres du groupe de travail syslog de leurs efforts pour mener des discussions qui ont apporté des solutions. Les auteurs tiennent aussi à remercier Balazs Scheidler, Tom Petch, et autres personnes de leurs apports sur les menaces sur la sécurité de syslog. Les auteurs remercient David Harrington de sa relecture détaillée du contenu et de la grammaire du document et Pasi Eronen de ses contributions aux sections d'authentification et d'autorisation  de certificat.

 	9.	Références
 	9.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. (MàJ par RFC8174)

[RFC5234]	D. Crocker, P. Overell, "BNF augmenté pour les spécifications de syntaxe : ABNF", janvier 2008. (STD0068)

[RFC5246]	T. Dierks, E. Rescorla, "Version 1.2 du protocole de sécurité de la couche Transport (TLS)", DOI 10.17487/RFC5246, août 2008. (P.S. ; remplace RFC3268, 4346, 4366 ; MàJ RFC4492 ; rendue obsolète par la RFC8446)

[RFC5280]	D. Cooper et autres, "Profil de certificat d'infrastructure de clé publique X.509 et de liste de révocation de certificat (CRL) pour l'Internet", mai 2008. (Remplace les RFC3280, RFC4325, RFC4630) (P.S. ; MàJ par RFC8398, 8399)

[RFC5424]	R. Gerhards, "Le protocole Syslog", mars 2009. (Remplace la RFC3164, P. S.)

 	9.2	Références pour information

[RFC4572]	J. Lennox, "Transport sur support en mode connexion sur le protocole de sécurité de la couche Transport (TLS) dans le protocole de description de session (SDP)", juillet 2006. (MàJ RFC4145) (P.S. ; remplacée par RFC8122)

[RFC5848]	J. Kelsey, J. Callas, A. Clemm, "Messages Syslog signés", mai 2010. (P. S.)

 	Adresse des éditeurs

Fuyou Miao	Yuzhi Ma	Joseph Salowey	
Huawei Technologies	Huawei Technologies	Cisco Systems, Inc.	
mél : miaofy@huawei.com	mél : myz@huawei.com	mél : jsalowey@cisco.com	
URI : www.huawei.com	URI : www.huawei.com