[要約] RFC 5425は、SyslogのためのTransport Layer Security (TLS) Transport Mappingに関する仕様です。このRFCの目的は、Syslogのセキュリティを向上させるために、TLSを使用した信頼性のあるトランスポートを提供することです。
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.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
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およびこのドキュメントの公開日（http://trustee.ietf.org/license-info）に有効なIETFドキュメントに関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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.
このドキュメントでは、Syslogメッセージの輸送に安全な接続を提供するための輸送層セキュリティ（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
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.
このドキュメントでは、Syslog [RFC5424]メッセージの輸送に安全な接続を提供するための輸送層セキュリティ（TLS [RFC5246]）の使用について説明しています。このドキュメントでは、SYSLOGに対するセキュリティの脅威と、TLSを使用してそのような脅威に対抗する方法について説明しています。
The following definitions are used in this document:
このドキュメントでは、次の定義が使用されています。
o An "originator" generates syslog content to be carried in a message.
o 「Originator」は、メッセージに掲載されるSyslogコンテンツを生成します。
o A "collector" gathers syslog content for further analysis.
o 「コレクター」は、さらなる分析のためにSyslogコンテンツを収集します。
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 「Transport Sender」は、Syslogメッセージを特定のトランスポートプロトコルに渡します。
o A "transport receiver" takes syslog messages from a specific transport protocol.
o 「トランスポートレシーバー」は、特定のトランスポートプロトコルからSyslogメッセージを受け取ります。
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].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" は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.
Syslogメッセージは、意図したコレクターに到着するためにいくつかのホップを通過する場合があります。ネットワークは別のセキュリティドメインにあるか、オリジネーター、リレー、またはコレクターとは異なるセキュリティレベルにあるため、一部の中間ネットワークは、オリジネーター、リレー、または受信機によって信頼されない場合があります。別のセキュリティ上の懸念は、オリジネーター、リレー、またはレシーバー自体が安全でないネットワークにあることです。
There are several threats to be addressed for syslog security. The primary threats are: 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.
Syslogセキュリティのために対処すべきいくつかの脅威があります。主な脅威は次のとおりです。許可されていない輸送送信者は、正当なトランスポートレシーバーにメッセージを送信したり、不正な交通機関の受信者が合法的な輸送送信者を欺き、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メッセージの内容を調べて、情報への不正アクセスを獲得する場合があります。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 メッセージストリームの変更。攻撃者は、一連のメッセージから1つ以上のSyslogメッセージを削除したり、メッセージを再生したり、配信シーケンスを変更したりできます。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 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.
注：この安全なトランスポート（つまり、TLS）は、ホップバイホップでのみSyslogトランスポートを保護し、Syslogメッセージの内容には関心がありません。特に、トランスポート送信者の認証されたID（例：証明書の件名）は、必ずしもSyslogメッセージのホスト名フィールドに関連しているわけではありません。Syslogメッセージの原点の認証が必要な場合、[Sys-Sign]を使用できます。
A syslog transport sender is always a TLS client and a transport receiver is always a TLS server.
Syslog Transport Senderは常に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_WITH_AES_128_CBC_SHAであるCipher Suiteを実装するための必須をサポートする必要があります。このドキュメントは、TLSの将来のバージョンに適用されると想定されています。この場合、実装されたバージョンのCipherスイートを実装するための必須をサポートする必要があります。
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:
Syslog Transport Sender（TLSクライアント）とSyslog Transport Receiver（TLS Server）の両方が、証明書ベースの認証を実装する必要があります。これは、証明書を検証し、ピアが対応する秘密鍵を持っていることを確認することで構成されています。後者の部分は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ピアは、1つ以上の信頼アンカー（通常はルートCA（認定機関）証明書）で構成されており、サブジェクト名と公開鍵の間の拘束力を確認できます。Syslog Transport SenderおよびReceiver（つまり、主題名が認定当事者を表すことを確認することを確認する）を承認するために必要な追加のポリシーコントロールは、セクション5で説明されています。この方法は、公開キーインフラストラクチャ（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:
指紋を生成するメカニズムは、暗号化的に強力なアルゴリズムを使用して、derエンコードされた証明書のハッシュを取得し、結果をコロン分離された16進バイトに変換することです。指紋値が表示または構成されている場合、指紋は、ハッシュ関数に続いてコロンを識別するASCIIラベルで準備されます。実装は、SHA-1をハッシュアルゴリズムとしてサポートし、ASCIIラベル「SHA-1」を使用してSHA-1アルゴリズムを識別する必要があります。SHA-1ハッシュの長さは20バイトで、対応する指紋弦の長さは65文字です。証明書指紋の例は次のとおりです。
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:
すべてのsyslogメッセージは、TLS「アプリケーションデータ」として送信する必要があります。複数のSYSLOGメッセージを1つのTLSレコードに含めること、または複数のTLSレコードに単一のSYSLOGメッセージを転送する可能性があります。アプリケーションデータは、次のABNF [RFC5234]式で定義されます。
APPLICATION-DATA = 1*SYSLOG-FRAME
SYSLOG-FRAME = MSG-LEN SP SYSLOG-MSG
MSG-LEN = NONZERO-DIGIT *DIGIT
msg-len = non zero-digit *桁
SP = %d32
NONZERO-DIGIT = %d49-57
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フレームのsyslog-msgのオクテット数です。トランスポートレシーバーは、メッセージの長さを使用して、syslogメッセージを区切る必要があります。メッセージの長さ自体の上限はありません。ただし、相互運用性のベースラインを確立するために、この仕様では、輸送レシーバーが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).
輸送送信者は、接続が後でsyslogメッセージを配信するとは予想されない場合、関連するTLS接続を閉じる必要があります。接続を閉じる前に、TLS close_notifyアラートを送信する必要があります。トランスポート送信者（TLSクライアント）は、トランスポートレシーバーのclose_notifyアラートを待機せず、接続を閉じるだけで、トランスポートレシーバー（TLSサーバー）側に不完全なクローズを生成することを選択できます。トランスポートレシーバーがトランスポート送信者からclose_notifyを取得したら、接続が輸送送信者によって既に閉じられていることに気付かない限り、close_notifyで返信する必要があります（たとえば、閉鎖は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.
接続から長い間データが受信されない場合（アプリケーションが「長い」意味を決定する場合）、トランスポートレシーバーが接続を閉じることができます。トランスポートレシーバー（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 Transport ReceiversおよびSyslog Transport Sendersによって実装される可能性のあるセキュリティポリシーの一部について説明します。セキュリティポリシーは、認証と承認の要件を説明しています。このセクションのポリシーのリストは網羅的ではなく、他のポリシーが実装される場合があります。
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 '*'（ascii 42）ワイルドカードの文字は、subjectaltname拡張機能のdnsnameで許可されています（およびホスト名を保存するために使用される場合は共通名で）が、その値の左端（最も重要ではない）DNSラベルとしてのみです。このワイルドカードは、サーバー名の左端のDNSラベルと一致します。つまり、件名 *.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 ローカルで構成された名前が国際化されたドメイン名である場合、適合実装は、[RFC5280]のセクション7で指定されているように、比較を実行するためにASCII互換エンコード（ACE）形式に変換する必要があります。
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 実装は、件名拡張機能に保存されているiPaddressに対してローカルで構成されたIPアドレスと一致することをサポートする場合があります。この場合、[RFC5280]、セクション4.2.1.6で指定されているように、ローカルで構成されたIPアドレスはオクテット文字列に変換されます。このオクテット文字列が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.
一部の環境では、syslogデータの信頼性は重要ではないか、他の手段で検証可能であるため、輸送受信者は輸送送信者からのデータを受け入れる場合があります。これを達成するために、トランスポートレシーバーはトランスポート送信者認証をスキップできます（TLSでクライアント認証を要求しないか、証明書を受け入れることで）。この場合、輸送受信機は認証され、承認されていますが、このポリシーはセクション2で説明されている輸送送信者の魔術師の脅威から保護しません。このポリシーの使用は、この理由で一般的に推奨されません。
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.
一部の環境では、Syslogデータの機密性は重要ではないため、輸送レシーバーにメッセージが送信されます。これを達成するために、トランスポート送信者は（証明書を受け入れることにより）輸送レシーバー認証をスキップできます。このポリシーは輸送送信者を認証および承認しますが、セクション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では、展開される可能性のあるさまざまなセキュリティポリシーについて説明します。セクション2の脅威は、セクション5.1および5.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.
トランスポートレシーバーが輸送送信者を認証しない場合、攻撃者からのデータを受け入れる場合があります。データのソースを認証する別の方法がない限り、データを信頼するべきではありません。これは、Syslogデータを使用してセキュリティインシデントを検出して対応する場合に特に重要です。輸送受信者は、輸送送信者を認証しない場合、サービスの拒否、リソース消費、およびその他の攻撃に対する脆弱性を高める可能性があります。攻撃に対する脆弱性が増加するため、このタイプの構成は推奨されません。
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は、キーワード「syslog-tls」を備えた「登録ポート番号」の範囲にTCPポート番号6514を割り当てました。このドキュメントで定義されているように、このポートは、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 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.
著者は、エリック・レスコルラ、レイナー・ゲルハード、トム・ペッチ、アントン・オクミアンスキー、バラズ・シードラー、バート・ウィジネン、マーティン・シュエット、クリス・ロンヴィック、およびSyslogワーキンググループのメンバーが議論を解決するための努力について感謝しています。著者はまた、Syslogのセキュリティの脅威に関する意見について、Balazs Scheidler、Tom Petch、その他の人に感謝したいと思います。著者は、ドキュメントの内容と文法の詳細なレビューと、証明書の認証と承認セクションへの貢献についてPasi Eronenについて、David Harringtonに承認したいと考えています。
[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の増強」、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、「The Transport Layer Security（TLS）Protocolバージョン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 Parine Key Infrastructure証明書および証明書失効リスト（CRL）プロファイル"、RFC 5280、2008年5月。
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
[RFC5424] Gerhards、R。、「Syslog Protocol」、RFC 5424、2009年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。、「署名されたSyslogメッセージ」、2007年10月、進行中の作業。
Authors' Addresses
著者のアドレス
Fuyou Miao (editor) Huawei Technologies No. 3, Xinxi Rd Shangdi Information Industry Base Haidian District, Beijing 100085 P. R. China
Fuyou Miao（編集者）Huawei Technologies No. 3、Xinxi Rd Shangdi Information Industry Base Haidian District、Beijing 100085 P. R. China
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
Yuzhi MA（編集者）Huawei Technologies No. 3、Xinxi Rd Shangdi Information Industry Base Haidian District、Beijing 100085 P. R. China
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（編集者）Cisco Systems、Inc。2901 3rd。Ave Seattle、WA 98121 USA
EMail: jsalowey@cisco.com