Network Working Group F. Miao, Ed.
Request for Comments: 5425 Y. Ma, Ed.
Category: Standards Track Huawei Technologies
J. Salowey, Ed.
Cisco Systems, Inc.
March 2009
Network Working Group F. Miao, Ed.
Request for Comments: 5425 Y. Ma, Ed.
Category: Standards Track Huawei Technologies
J. Salowey, Ed.
Cisco Systems, Inc.
March 2009
Transport Layer Security (TLS) Transport Mapping for Syslog
Syslog的传输层安全性（TLS）传输映射
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Abstract
摘要
This document describes the use of Transport Layer Security (TLS) to provide a secure connection for the transport of syslog messages. This document describes the security threats to syslog and how TLS can be used to counter such threats.
本文档介绍如何使用传输层安全性（TLS）为系统日志消息的传输提供安全连接。本文档描述了对syslog的安全威胁，以及如何使用TLS来应对此类威胁。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Terminology ................................................3
2. Security Requirements for Syslog ................................3
3. Using TLS to Secure Syslog ......................................4
4. Protocol Elements ...............................................5
4.1. Port Assignment ............................................5
4.2. Initiation .................................................5
4.2.1. Certificate-Based Authentication ....................5
4.2.2. Certificate Fingerprints ............................6
4.2.3. Cryptographic Level .................................7
4.3. Sending Data ...............................................7
4.3.1. Message Length ......................................7
4.4. Closure ....................................................8
5. Security Policies ...............................................8
5.1. End-Entity Certificate Based Authorization .................8
5.2. Subject Name Authorization .................................9
5.3. Unauthenticated Transport Sender ...........................9
5.4. Unauthenticated Transport Receiver ........................10
5.5. Unauthenticated Transport Receiver and Sender .............10
6. Security Considerations ........................................10
6.1. Authentication and Authorization Policies .................10
6.2. Name Validation ...........................................11
6.3. Reliability ...............................................11
7. IANA Considerations ............................................11
7.1. Port Number ...............................................11
8. Acknowledgments ................................................11
9. References .....................................................12
9.1. Normative References ......................................12
9.2. Informative References ....................................12
1. Introduction ....................................................3
1.1. Terminology ................................................3
2. Security Requirements for Syslog ................................3
3. Using TLS to Secure Syslog ......................................4
4. Protocol Elements ...............................................5
4.1. Port Assignment ............................................5
4.2. Initiation .................................................5
4.2.1. Certificate-Based Authentication ....................5
4.2.2. Certificate Fingerprints ............................6
4.2.3. Cryptographic Level .................................7
4.3. Sending Data ...............................................7
4.3.1. Message Length ......................................7
4.4. Closure ....................................................8
5. Security Policies ...............................................8
5.1. End-Entity Certificate Based Authorization .................8
5.2. Subject Name Authorization .................................9
5.3. Unauthenticated Transport Sender ...........................9
5.4. Unauthenticated Transport Receiver ........................10
5.5. Unauthenticated Transport Receiver and Sender .............10
6. Security Considerations ........................................10
6.1. Authentication and Authorization Policies .................10
6.2. Name Validation ...........................................11
6.3. Reliability ...............................................11
7. IANA Considerations ............................................11
7.1. Port Number ...............................................11
8. Acknowledgments ................................................11
9. References .....................................................12
9.1. Normative References ......................................12
9.2. Informative References ....................................12
This document describes the use of Transport Layer Security (TLS [RFC5246]) to provide a secure connection for the transport of syslog [RFC5424] messages. This document describes the security threats to syslog and how TLS can be used to counter such threats.
本文档介绍了如何使用传输层安全性（TLS[RFC5246]）为syslog[RFC5424]消息的传输提供安全连接。本文档描述了对syslog的安全威胁，以及如何使用TLS来应对此类威胁。
The following definitions are used in this document:
本文件中使用了以下定义：
o An "originator" generates syslog content to be carried in a message.
o “发起者”生成要在消息中携带的系统日志内容。
o A "collector" gathers syslog content for further analysis.
o “收集器”收集系统日志内容以供进一步分析。
o A "relay" forwards messages, accepting messages from originators or other relays, and sending them to collectors or other relays.
o “中继”转发消息，接受发起者或其他中继发送的消息，并将其发送给收集器或其他中继。
o A "transport sender" passes syslog messages to a specific transport protocol.
o “传输发送方”将系统日志消息传递给特定的传输协议。
o A "transport receiver" takes syslog messages from a specific transport protocol.
o “传输接收器”从特定的传输协议获取系统日志消息。
o A "TLS client" is an application that can initiate a TLS connection by sending a Client Hello to a server.
o “TLS客户端”是一个应用程序，它可以通过向服务器发送客户端Hello来启动TLS连接。
o A "TLS server" is an application that can receive a Client Hello from a client and reply with a Server Hello.
o “TLS服务器”是一个应用程序，它可以从客户机接收客户机Hello，并用服务器Hello回复。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
Syslog messages may transit several hops to arrive at the intended collector. Some intermediary networks may not be trusted by the originator, relay, or receiver because the network is in a different security domain or at a different security level from the originator, relay, or collector. Another security concern is that the originator, relay, or receiver itself is in an insecure network.
系统日志消息可能会经过几个跃点到达预期的收集器。某些中间网络可能不受发起者、中继或接收者的信任，因为该网络位于不同的安全域中，或者与发起者、中继或接收者处于不同的安全级别。另一个安全问题是发起者、中继或接收器本身处于不安全的网络中。
There are several threats to be addressed for syslog security. The primary threats are:
syslog安全性需要解决几个威胁。主要威胁是：
o Masquerade. An unauthorized transport sender may send messages to a legitimate transport receiver, or an unauthorized transport receiver may try to deceive a legitimate transport sender into sending syslog messages to it.
o 掩藏未经授权的传输发送方可能会向合法的传输接收方发送消息，或者未经授权的传输接收方可能会试图欺骗合法的传输发送方向其发送syslog消息。
o Modification. An attacker between the transport sender and the transport receiver may modify an in-transit syslog message and then forward the message to the transport receiver. Such modification may make the transport receiver misunderstand the message or cause it to behave in undesirable ways.
o 修改传输发送方和传输接收方之间的攻击者可能会修改传输中的syslog消息，然后将该消息转发给传输接收方。这种修改可能会使传输接收方误解消息或导致其以不希望的方式运行。
o Disclosure. An unauthorized entity may examine the contents of the syslog messages, gaining unauthorized access to the information. Some data in syslog messages is sensitive and may be useful to an attacker, such as the password of an authorized administrator or user.
o 披露未经授权的实体可能会检查系统日志消息的内容，从而获得对信息的未经授权访问。syslog消息中的某些数据非常敏感，可能对攻击者有用，例如授权管理员或用户的密码。
The secondary threat is:
第二个威胁是：
o Message stream modification. An attacker may delete one or more syslog messages from a series of messages, replay a message, or alter the delivery sequence. The syslog protocol itself is not based on message order. However, an event in a syslog message may relate semantically to events in other messages, so message ordering may be important to understanding a sequence of events.
o 消息流修改。攻击者可以从一系列消息中删除一条或多条系统日志消息、重播消息或更改传递顺序。syslog协议本身并不基于消息顺序。然而，syslog消息中的事件可能在语义上与其他消息中的事件相关，因此消息顺序对于理解事件序列可能很重要。
The following threats are deemed to be of lesser importance for syslog, and are not addressed in this document:
以下威胁被视为对syslog不太重要，本文档中未提及：
o Denial of Service
o 拒绝服务
o Traffic Analysis
o 流量分析
TLS can be used as a secure transport to counter all the primary threats to syslog described above:
TLS可用作安全传输，以应对上述syslog的所有主要威胁：
o Confidentiality to counter disclosure of the message contents.
o 信息内容的保密性。
o Integrity-checking to counter modifications to a message on a hop-by-hop basis.
o 完整性检查，以逐跳方式对消息的修改进行计数器。
o Server or mutual authentication to counter masquerade.
o 服务器或相互身份验证来对抗伪装。
Note: This secure transport (i.e., TLS) only secures syslog transport in a hop-by-hop manner, and is not concerned with the contents of syslog messages. In particular, the authenticated identity of the
注意：此安全传输（即TLS）仅以逐跳方式保护系统日志传输，与系统日志消息的内容无关。特别是，用户的经过身份验证的身份
transport sender (e.g., subject name in the certificate) is not necessarily related to the HOSTNAME field of the syslog message. When authentication of syslog message origin is required, [SYS-SIGN] can be used.
传输发送方（例如，证书中的使用者名称）不一定与系统日志消息的主机名字段相关。当需要对syslog消息源进行身份验证时，可以使用[SYS-SIGN]。
A syslog transport sender is always a TLS client and a transport receiver is always a TLS server.
syslog传输发送方始终是TLS客户端，传输接收方始终是TLS服务器。
The TCP port 6514 has been allocated as the default port for syslog over TLS, as defined in this document.
TCP端口6514已被分配为TLS上syslog的默认端口，如本文档中所定义。
The transport sender should initiate a connection to the transport receiver and then send the TLS Client Hello to begin the TLS handshake. When the TLS handshake has finished, the transport sender MAY then send the first syslog message.
传输发送方应启动与传输接收方的连接，然后发送TLS客户端Hello以开始TLS握手。TLS握手完成后，传输发送方可以发送第一条syslog消息。
TLS typically uses certificates [RFC5280] to authenticate peers. Implementations MUST support TLS 1.2 [RFC5246] and are REQUIRED to support the mandatory to implement cipher suite, which is TLS_RSA_WITH_AES_128_CBC_SHA. This document is assumed to apply to future versions of TLS, in which case the mandatory to implement cipher suite for the implemented version MUST be supported.
TLS通常使用证书[RFC5280]对对等方进行身份验证。实现必须支持TLS 1.2[RFC5246]，并且必须支持强制实现密码套件，即TLS_RSA_和_AES_128_CBC_SHA。假定本文件适用于TLS的未来版本，在这种情况下，必须支持强制实施实施版本的密码套件。
Both syslog transport sender (TLS client) and syslog transport receiver (TLS server) MUST implement certificate-based authentication. This consists of validating the certificate and verifying that the peer has the corresponding private key. The latter part is performed by TLS. To ensure interoperability between clients and servers, the following methods for certificate validation SHALL be implemented:
系统日志传输发送方（TLS客户端）和系统日志传输接收方（TLS服务器）都必须实现基于证书的身份验证。这包括验证证书和验证对等方是否具有相应的私钥。后一部分由TLS执行。为确保客户端和服务器之间的互操作性，应实施以下证书验证方法：
o Certification path validation: The TLS peer is configured with one or more trust anchors (typically root CA (certification authority) certificates), which allow it to verify a binding between the subject name and the public key. Additional policy controls needed for authorizing the syslog transport sender and receiver (i.e., verifying that the subject name represents an authorized party) are described in Section 5. Certification path validation is performed as defined in [RFC5280]. This method is useful where there is a Public Key Infrastructure (PKI) deployment.
o 认证路径验证：TLS对等方配置有一个或多个信任锚（通常是根CA（证书颁发机构）证书），允许其验证使用者名称和公钥之间的绑定。第5节描述了授权syslog传输发送方和接收方（即验证主题名称是否代表授权方）所需的其他策略控制。按照[RFC5280]中的定义执行认证路径验证。在部署公钥基础设施（PKI）的情况下，此方法非常有用。
o End-entity certificate matching: The transport sender or receiver is configured with information necessary to identify the valid end-entity certificates of its authorized peers. The end-entity certificates can be self-signed, and no certification path validation is needed. Implementations MUST support certificate fingerprints in Section 4.2.2 and MAY allow other formats for end-entity certificates such as a DER-encoded certificate. This method provides an alternative to a PKI that is simple to deploy and still maintains a reasonable level of security.
o 终端实体证书匹配：传输发送方或接收方配置了识别其授权对等方的有效终端实体证书所需的信息。终端实体证书可以是自签名的，不需要证书路径验证。实现必须支持第4.2.2节中的证书指纹，并允许终端实体证书的其他格式，如DER编码证书。该方法提供了一种PKI的替代方案，该方案易于部署，并且仍然保持合理的安全级别。
Both transport receiver and transport sender implementations MUST provide means to generate a key pair and self-signed certificate in the case that a key pair and certificate are not available through another mechanism.
传输接收方和传输发送方实现都必须提供在密钥对和证书无法通过另一种机制获得的情况下生成密钥对和自签名证书的方法。
The transport receiver and transport sender SHOULD provide mechanisms to record the end-entity certificate for the purpose of correlating it with the sent or received data.
传输接收方和传输发送方应提供记录终端实体证书的机制，以便将其与发送或接收的数据关联起来。
Both client and server implementations MUST make the certificate fingerprints for their certificate available through a management interface. The labels for the algorithms are taken from the textual names of the hash functions as defined in the IANA registry "Hash Function Textual Names" allocated in [RFC4572].
客户端和服务器实现都必须通过管理接口使其证书的证书指纹可用。算法的标签取自[RFC4572]中分配的IANA注册表“哈希函数文本名称”中定义的哈希函数的文本名称。
The mechanism to generate a fingerprint is to take the hash of the DER-encoded certificate using a cryptographically strong algorithm, and convert the result into colon-separated, hexadecimal bytes, each represented by 2 uppercase ASCII characters. When a fingerprint value is displayed or configured, the fingerprint is prepended with an ASCII label identifying the hash function followed by a colon. Implementations MUST support SHA-1 as the hash algorithm and use the ASCII label "sha-1" to identify the SHA-1 algorithm. The length of a SHA-1 hash is 20 bytes and the length of the corresponding fingerprint string is 65 characters. An example certificate fingerprint is:
The mechanism to generate a fingerprint is to take the hash of the DER-encoded certificate using a cryptographically strong algorithm, and convert the result into colon-separated, hexadecimal bytes, each represented by 2 uppercase ASCII characters. When a fingerprint value is displayed or configured, the fingerprint is prepended with an ASCII label identifying the hash function followed by a colon. Implementations MUST support SHA-1 as the hash algorithm and use the ASCII label "sha-1" to identify the SHA-1 algorithm. The length of a SHA-1 hash is 20 bytes and the length of the corresponding fingerprint string is 65 characters. An example certificate fingerprint is:translate error, please retry
sha-1:E1:2D:53:2B:7C:6B:8A:29:A2:76:C8:64:36:0B:08:4B:7A:F1:9E:9D
sha-1:E1:2D:53:2B:7C:6B:8A:29:A2:76:C8:64:36:0B:08:4B:7A:F1:9E:9D
During validation the hash is extracted from the fingerprint and compared against the hash calculated over the received certificate.
在验证期间，将从指纹中提取哈希值，并将其与在接收到的证书上计算的哈希值进行比较。
Syslog applications SHOULD be implemented in a manner that permits administrators, as a matter of local policy, to select the cryptographic level and authentication options they desire.
Syslog应用程序的实现方式应允许管理员根据本地策略选择所需的加密级别和身份验证选项。
TLS permits the resumption of an earlier TLS session or the use of another active session when a new session is requested, in order to save the expense of another full TLS handshake. The security parameters of the resumed session are reused for the requested session. The security parameters SHOULD be checked against the security requirements of the requested session to make sure that the resumed session provides proper security.
TLS允许在请求新会话时恢复先前的TLS会话或使用另一个活动会话，以节省另一次完整TLS握手的费用。恢复会话的安全参数将重新用于请求的会话。应根据请求会话的安全要求检查安全参数，以确保恢复的会话提供适当的安全性。
All syslog messages MUST be sent as TLS "application data". It is possible for multiple syslog messages to be contained in one TLS record or for a single syslog message to be transferred in multiple TLS records. The application data is defined with the following ABNF [RFC5234] expression:
所有系统日志消息必须作为TLS“应用程序数据”发送。可以在一个TLS记录中包含多个系统日志消息，也可以在多个TLS记录中传输单个系统日志消息。应用程序数据由以下ABNF[RFC5234]表达式定义：
APPLICATION-DATA = 1*SYSLOG-FRAME
APPLICATION-DATA = 1*SYSLOG-FRAME
SYSLOG-FRAME = MSG-LEN SP SYSLOG-MSG
SYSLOG-FRAME = MSG-LEN SP SYSLOG-MSG
MSG-LEN = NONZERO-DIGIT *DIGIT
MSG-LEN=非零位*位
SP = %d32
SP = %d32
NONZERO-DIGIT = %d49-57
NONZERO-DIGIT = %d49-57
DIGIT = %d48 / NONZERO-DIGIT
DIGIT = %d48 / NONZERO-DIGIT
SYSLOG-MSG is defined in the syslog protocol [RFC5424].
SYSLOG-MSG在SYSLOG协议[RFC5424]中定义。
The message length is the octet count of the SYSLOG-MSG in the SYSLOG-FRAME. A transport receiver MUST use the message length to delimit a syslog message. There is no upper limit for a message length per se. However, in order to establish a baseline for interoperability, this specification requires that a transport receiver MUST be able to process messages with a length up to and including 2048 octets. Transport receivers SHOULD be able to process messages with lengths up to and including 8192 octets.
消息长度是SYSLOG-FRAME中SYSLOG-MSG的八位字节计数。传输接收方必须使用消息长度来分隔系统日志消息。消息长度本身没有上限。然而，为了建立互操作性基线，本规范要求传输接收器必须能够处理长度不超过2048个八位字节的消息。传输接收器应能够处理长度不超过8192个八位字节的消息。
A transport sender MUST close the associated TLS connection if the connection is not expected to deliver any syslog messages later. It MUST send a TLS close_notify alert before closing the connection. A transport sender (TLS client) MAY choose to not wait for the transport receiver's close_notify alert and simply close the connection, thus generating an incomplete close on the transport receiver (TLS server) side. Once the transport receiver gets a close_notify from the transport sender, it MUST reply with a close_notify unless it becomes aware that the connection has already been closed by the transport sender (e.g., the closure was indicated by TCP).
如果以后不希望连接传递任何系统日志消息，则传输发送方必须关闭关联的TLS连接。它必须在关闭连接之前发送TLS close_notify警报。传输发送方（TLS客户端）可以选择不等待传输接收方的close_notify警报，只关闭连接，从而在传输接收方（TLS服务器）端生成不完全关闭。一旦传输接收方收到传输发送方发出的关闭通知，它必须回复关闭通知，除非它意识到传输发送方已经关闭了连接（例如，TCP指示关闭）。
When no data is received from a connection for a long time (where the application decides what "long" means), a transport receiver MAY close the connection. The transport receiver (TLS server) MUST attempt to initiate an exchange of close_notify alerts with the transport sender before closing the connection. Transport receivers that are unprepared to receive any more data MAY close the connection after sending the close_notify alert, thus generating an incomplete close on the transport sender side.
当长时间没有从连接接收到数据时（应用程序决定“long”是什么意思），传输接收器可以关闭连接。在关闭连接之前，传输接收方（TLS服务器）必须尝试与传输发送方交换close_notify警报。不准备接收更多数据的传输接收器可能在发送close_notify警报后关闭连接，从而在传输发送方端生成不完全关闭。
Different environments have different security requirements and therefore would deploy different security policies. This section discusses some of the security policies that may be implemented by syslog transport receivers and syslog transport senders. The security policies describe the requirements for authentication and authorization. The list of policies in this section is not exhaustive and other policies MAY be implemented.
不同的环境有不同的安全需求，因此会部署不同的安全策略。本节讨论syslog传输接收方和syslog传输发送方可能实施的一些安全策略。安全策略描述了身份验证和授权的要求。本节中的政策列表并非详尽无遗，可能会实施其他政策。
If the peer does not meet the requirements of the security policy, the TLS handshake MUST be aborted with an appropriate TLS alert.
如果对等方不符合安全策略的要求，则必须使用适当的TLS警报中止TLS握手。
In the simplest case, the transport sender and receiver are configured with information necessary to identity the valid end-entity certificates of its authorized peers.
在最简单的情况下，传输发送方和接收方配置了识别其授权对等方的有效终端实体证书所需的信息。
Implementations MUST support specifying the authorized peers using certificate fingerprints, as described in Section 4.2.1 and Section 4.2.2.
实现必须支持使用证书指纹指定授权对等方，如第4.2.1节和第4.2.2节所述。
Implementations MUST support certification path validation [RFC5280]. In addition, they MUST support specifying the authorized peers using locally configured host names and matching the name against the certificate as follows.
实现必须支持证书路径验证[RFC5280]。此外，它们必须支持使用本地配置的主机名指定授权的对等方，并根据证书匹配名称，如下所示。
o Implementations MUST support matching the locally configured host name against a dNSName in the subjectAltName extension field and SHOULD support checking the name against the common name portion of the subject distinguished name.
o 实现必须支持将本地配置的主机名与subjectAltName扩展字段中的dNSName进行匹配，并应支持将名称与主题可分辨名称的公用名称部分进行检查。
o The '*' (ASCII 42) wildcard character is allowed in the dNSName of the subjectAltName extension (and in common name, if used to store the host name), but only as the left-most (least significant) DNS label in that value. This wildcard matches any left-most DNS label in the server name. That is, the subject *.example.com matches the server names a.example.com and b.example.com, but does not match example.com or a.b.example.com. Implementations MUST support wildcards in certificates as specified above, but MAY provide a configuration option to disable them.
o subjectAltName扩展名的dNSName中允许使用“*”（ASCII 42）通配符（如果用于存储主机名，则允许使用通用名），但只能作为该值中最左侧（最低有效）的DNS标签。此通配符与服务器名称中最左边的DNS标签匹配。也就是说，subject*.example.com与服务器名a.example.com和b.example.com匹配，但与example.com或a.b.example.com不匹配。实现必须支持上面指定的证书中的通配符，但可以提供一个配置选项来禁用它们。
o Locally configured names MAY contain the wildcard character to match a range of values. The types of wildcards supported MAY be more flexible than those allowed in subject names, making it possible to support various policies for different environments. For example, a policy could allow for a trust-root-based authorization where all credentials issued by a particular CA trust root are authorized.
o 本地配置的名称可能包含通配符以匹配一系列值。支持的通配符类型可能比主题名称中允许的通配符类型更灵活，从而可以为不同的环境支持各种策略。例如，策略可以允许基于信任根的授权，其中授权特定CA信任根颁发的所有凭据。
o If the locally configured name is an internationalized domain name, conforming implementations MUST convert it to the ASCII Compatible Encoding (ACE) format for performing comparisons, as specified in Section 7 of [RFC5280].
o 如果本地配置的名称是国际化域名，则一致性实现必须将其转换为ASCII兼容编码（ACE）格式以进行比较，如[RFC5280]第7节所述。
o Implementations MAY support matching a locally configured IP address against an iPAddress stored in the subjectAltName extension. In this case, the locally configured IP address is converted to an octet string as specified in [RFC5280], Section 4.2.1.6. A match occurs if this octet string is equal to the value of iPAddress in the subjectAltName extension.
o 实现可能支持将本地配置的IP地址与subjectAltName扩展中存储的IP地址进行匹配。在这种情况下，本地配置的IP地址转换为[RFC5280]第4.2.1.6节中规定的八位字节字符串。如果此八位字节字符串等于subjectAltName扩展名中的iPAddress值，则会发生匹配。
In some environments the authenticity of syslog data is not important or is verifiable by other means, so transport receivers may accept data from any transport sender. To achieve this, the transport receiver can skip transport sender authentication (by not requesting
在某些环境中，系统日志数据的真实性并不重要，或者可以通过其他方式进行验证，因此传输接收方可以接受来自任何传输发送方的数据。为此，传输接收方可以跳过传输发送方身份验证（通过不请求
client authentication in TLS or by accepting any certificate). In this case, the transport receiver is authenticated and authorized, however this policy does not protect against the threat of transport sender masquerade described in Section 2. The use of this policy is generally NOT RECOMMENDED for this reason.
client authentication in TLS or by accepting any certificate). In this case, the transport receiver is authenticated and authorized, however this policy does not protect against the threat of transport sender masquerade described in Section 2. The use of this policy is generally NOT RECOMMENDED for this reason.translate error, please retry
In some environments the confidentiality of syslog data is not important, so messages are sent to any transport receiver. To achieve this, the transport sender can skip transport receiver authentication (by accepting any certificate). While this policy does authenticate and authorize the transport sender, it does not protect against the threat of transport receiver masquerade described in Section 2, leaving the data sent vulnerable to disclosure and modification. The use of this policy is generally NOT RECOMMENDED for this reason.
在某些环境中，系统日志数据的机密性并不重要，因此消息会发送到任何传输接收器。为此，传输发送方可以跳过传输接收方身份验证（通过接受任何证书）。虽然此策略确实对传输发送方进行身份验证和授权，但它不能防止第2节中描述的传输接收方伪装的威胁，从而使发送的数据容易被披露和修改。因此，通常不建议使用此策略。
In environments where security is not a concern at all, both the transport receiver and transport sender can skip authentication (as described in Sections 5.3 and 5.4). This policy does not protect against any of the threats described in Section 2 and is therefore NOT RECOMMENDED.
在完全不关心安全性的环境中，传输接收方和传输发送方都可以跳过身份验证（如第5.3节和第5.4节所述）。本政策不针对第2节所述的任何威胁提供保护，因此不建议使用本政策。
This section describes security considerations in addition to those in [RFC5246].
除[RFC5246]中的安全注意事项外，本节还介绍了安全注意事项。
Section 5 discusses various security policies that may be deployed. The threats in Section 2 are mitigated only if both the transport sender and transport receiver are properly authenticated and authorized, as described in Sections 5.1 and 5.2. These are the RECOMMENDED configurations for a default policy.
第5节讨论了可能部署的各种安全策略。只有当传输发送方和传输接收方都经过了第5.1节和第5.2节所述的适当身份验证和授权时，才能缓解第2节中的威胁。这些是默认策略的建议配置。
If the transport receiver does not authenticate the transport sender, it may accept data from an attacker. Unless it has another way of authenticating the source of the data, the data should not be trusted. This is especially important if the syslog data is going to be used to detect and react to security incidents. The transport receiver may also increase its vulnerability to denial of service, resource consumption, and other attacks if it does not authenticate the transport sender. Because of the increased vulnerability to attack, this type of configuration is NOT RECOMMENDED.
如果传输接收方未对传输发送方进行身份验证，则可能会接受来自攻击者的数据。除非它有另一种验证数据源的方法，否则数据不应被信任。如果系统日志数据将用于检测和响应安全事件，这一点尤为重要。如果传输接收方未对传输发送方进行身份验证，则传输接收方还可能增加其对拒绝服务、资源消耗和其他攻击的脆弱性。由于易受攻击的漏洞增加，不建议使用这种类型的配置。
If the transport sender does not authenticate the syslog transport receiver, then it may send data to an attacker. This may disclose sensitive data within the log information that is useful to an attacker, resulting in further compromises within the system. If a transport sender is operated in this mode, the data sent SHOULD be limited to data that is not valuable to an attacker. In practice this is very difficult to achieve, so this type of configuration is NOT RECOMMENDED.
如果传输发送方未对syslog传输接收方进行身份验证，则它可能会向攻击者发送数据。这可能会泄露日志信息中对攻击者有用的敏感数据，从而导致系统内的进一步危害。如果传输发送方在此模式下操作，则发送的数据应限于对攻击者没有价值的数据。实际上，这很难实现，因此不建议使用这种配置。
Forgoing authentication and authorization on both sides allows for man-in-the-middle, masquerade, and other types of attacks that can completely compromise integrity and confidentiality of the data. This type of configuration is NOT RECOMMENDED.
双方放弃身份验证和授权允许中间人攻击、伪装攻击和其他类型的攻击，这些攻击可以完全破坏数据的完整性和机密性。不建议使用这种类型的配置。
The subject name authorization policy authorizes the subject in the certificate against a locally configured name. It is generally not appropriate to obtain this name through other means, such as DNS lookup, since this introduces additional security vulnerabilities.
使用者名称授权策略根据本地配置的名称授权证书中的使用者。通常不适合通过其他方式（如DNS查找）获取此名称，因为这会引入额外的安全漏洞。
It should be noted that the syslog transport specified in this document does not use application-layer acknowledgments. TCP uses retransmissions to provide protection against some forms of data loss. However, if the TCP connection (or TLS session) is broken for some reason (or closed by the transport receiver), the syslog transport sender cannot always know what messages were successfully delivered to the syslog application at the other end.
应该注意，本文档中指定的syslog传输不使用应用层确认。TCP使用重传来防止某些形式的数据丢失。但是，如果TCP连接（或TLS会话）因某种原因中断（或被传输接收器关闭），syslog传输发送方无法始终知道哪些消息已成功传递到另一端的syslog应用程序。
IANA assigned TCP port number 6514 in the "Registered Port Numbers" range with the keyword "syslog-tls". This port will be the default port for syslog over TLS, as defined in this document.
IANA在“注册端口号”范围内为TCP端口号6514分配了关键字“syslog tls”。此端口将是本文档中定义的通过TLS的syslog的默认端口。
Authors appreciate Eric Rescorla, Rainer Gerhards, Tom Petch, Anton Okmianski, Balazs Scheidler, Bert Wijnen, Martin Schuette, Chris Lonvick, and members of the syslog working group for their effort on issues resolving discussion. Authors would also like to thank Balazs Scheidler, Tom Petch, and other persons for their input on security threats of syslog. The authors would like to acknowledge David
作者感谢Eric Rescorla、Rainer Gerhards、Tom Petch、Anton Okmianski、Balazs Scheidler、Bert Wijnen、Martin Schuette、Chris Lonvick以及syslog工作组成员在解决问题讨论方面所做的努力。作者还想感谢Balazs Scheidler、Tom Petch和其他人对syslog安全威胁的投入。作者要感谢David
Harrington for his detailed reviews of the content and grammar of the document and Pasi Eronen for his contributions to certificate authentication and authorization sections.
Harrington感谢他对文档内容和语法的详细审查，Pasi Eronen感谢他对证书认证和授权部分的贡献。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年5月。
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
[RFC5424]Gerhards，R.，“系统日志协议”，RFC 54242009年3月。
[RFC4572] Lennox, J., "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)", RFC 4572, July 2006.
[RFC4572]Lennox，J.，“会话描述协议（SDP）中传输层安全（TLS）协议上的面向连接的媒体传输”，RFC 4572，2006年7月。
[SYS-SIGN] Kelsey, J., "Signed syslog Messages", Work in Progress, October 2007.
[SYS-SIGN]Kelsey，J.，“已签名的系统日志消息”，正在进行的工作，2007年10月。
Authors' Addresses
作者地址
Fuyou Miao (editor) Huawei Technologies No. 3, Xinxi Rd Shangdi Information Industry Base Haidian District, Beijing 100085 P. R. China
缪福佑（编辑）中国北京市海淀区上地信息产业基地新西路3号华为技术有限公司100085
Phone: +86 10 8288 2008
EMail: miaofy@huawei.com
URI: www.huawei.com
Phone: +86 10 8288 2008
EMail: miaofy@huawei.com
URI: www.huawei.com
Yuzhi Ma (editor) Huawei Technologies No. 3, Xinxi Rd Shangdi Information Industry Base Haidian District, Beijing 100085 P. R. China
马玉芝（编辑）中国北京市海淀区上地信息产业基地新西路3号华为技术有限公司100085
Phone: +86 10 8288 2008
EMail: myz@huawei.com
URI: www.huawei.com
Phone: +86 10 8288 2008
EMail: myz@huawei.com
URI: www.huawei.com
Joseph Salowey (editor) Cisco Systems, Inc. 2901 3rd. Ave Seattle, WA 98121 USA
Joseph Salowey（编辑）思科系统公司，第2901-3页。美国华盛顿州西雅图大道98121号
EMail: jsalowey@cisco.com
EMail: jsalowey@cisco.com