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
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と、この文書（http://trustee.ietf.org/license-info）の発行日に有効なIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さ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.
この文書では、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「発信者は」メッセージで運ばれる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「トランスポート送信者は、」特定のトランスポートプロトコルに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を受け、こんにちはサーバーを使用して返信することができるアプリケーションです。
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のセキュリティに対処するには、いくつかの脅威があります。主な脅威は、次のとおりです。マスカレード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。トランスポート送信者と搬送受信機との間の攻撃者は、イントランジットシスログメッセージを変更し、輸送の受信機にメッセージを転送することができます。このような修飾は、トランスポートレシーバがメッセージを誤解させるか、それが望ましくない方法で動作することがあります。
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の輸送を確保し、システムログメッセージの内容に関係しません。具体的には、トランスポート送信者の認証されたアイデンティティ（例えば、証明書のサブジェクト名が）必ずしもシスログメッセージのホスト名フィールドには関係しません。シスログメッセージ起源の認証が必要な場合、[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ハンドシェイクを開始するためにTLSクライアントのHelloを送信する必要があります。 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ある暗号スイートを実装するために必須のをサポートするために必要とされます。この文書は、実装バージョンがサポートしなければならないために必須の暗号スイートを実装するその場合、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:
syslogのトランスポート送信者（TLSクライアント）およびSyslog転送受信機（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ピアは、1人のまたは複数の信頼アンカー（通常はルートCA（認証局）の証明書）で構成され、それがサブジェクト名と公開鍵の間の結合を確認することができます。 [RFC5280]で定義されるように（すなわち、サブジェクト名が正規のパーティを表すことを確認する）シスログ輸送送信側と受信側を認可するために必要な追加のポリシーコントロールはセクション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エンコードされた証明書のハッシュを取り、それぞれが2つの大文字ASCII文字で表される、コロンで区切られた16進数バイトに結果を変換することです。フィンガープリント値を表示または設定されている場合、指紋はコロンハッシュ関数を識別するASCIIラベルに付加されます。実装は、ハッシュアルゴリズムとしてSHA-1をサポートし、SHA-1アルゴリズムを識別するために、ASCIIラベル「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
SHA -1：J 1：月：53：AB：センス：医学：Doanh：カット：AAは：着陸：スプリット：64：36：0 B：08：4 B：地区：P 1：R：月
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
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 = NONZERO-DIGIT * DIGIT
SP = %d32
SP =％のD32
NONZERO-DIGIT = %d49-57
NONZERO-DIGIT =％d49-57
DIGIT = %d48 / NONZERO-DIGIT
DIGIT =％のD48 /非ゼロ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を取得したら、それは、接続が既に（例えば、閉鎖がTCPによって示された）搬送送信者によって閉じられたことを気付いていない限り、それはは、close_notifyで応答しなければなりません。
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転送受信機および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「*」（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実装はsubjectAltName拡張に格納されたIPアドレスに対してローカルに設定されたIPアドレスに一致するサポートすることができます。 [RFC5280]、セクション4.2.1.6で指定されるように、この場合には、ローカルに設定されたIPアドレスをオクテットストリングに変換されます。このオクテットストリングがsubjectAltName拡張におけるIPアドレスの値と等しい場合にマッチが起こります。
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節が展開されることができる様々なセキュリティポリシーを説明します。セクション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.
トランスポート・レシーバはトランスポートの送信者を認証しない場合は、攻撃者からのデータを受け入れることができます。それはデータのソースを認証する別の方法を持っていない限り、データは、信頼すべきではありません。 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.
両側の認証と認可を前述ことなman-in-the-middleを可能にし、マスカレード、およびそのデータの完全妥協完全性と機密できる他のタイプの攻撃。このタイプの構成は推奨されません。
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
著者は、議論を解決する問題についての彼らの努力のためにエリックレスコラ、レイナー・ガーハーズ、トム・ペッチ、アントンOkmianski、バラージュScheidler、バートWijnen、マーティンSchuette、クリスLonvick、およびsyslogワーキンググループのメンバーに感謝します。著者らはまたのsyslogのセキュリティ上の脅威に関する彼らの入力をバラージュScheidler、トム・ペッチ、および他の人に感謝したいと思います。著者はデイヴィッドを承認したいと思います
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.
証明書の認証と認可のセクションへの彼の貢献のための文書とパシEronenの内容と文法の彼の詳細なレビューのためにハリントン。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]クロッカー、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]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（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]クーパー、D.、Santesson、S.、ファレル、S.、Boeyen、S.、Housley氏、R.、およびW.ポーク、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）のプロフィール」、RFC 5280、2008年5月。
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
[RFC5424] Gerhards氏、R.、 "Syslogのプロトコル"、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]レノックス、J.、 "接続指向のセッション記述プロトコル（SDP）でTransport Layer Security（TLS）プロトコルを介してメディアトランスポート"、RFC 4572、2006年7月。
[SYS-SIGN] Kelsey, J., "Signed syslog Messages", Work in Progress, October 2007.
[SYS-SIGN]ケルシー、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
MIオーストリアのF U（エディタ）HU Aは技術であるなし。3、XラインでRDシャン低い地点情報産業ベースH地区、北京100085 P. R.中国
Phone: +86 10 8288 2008 EMail: miaofy@huawei.com URI: www.huawei.com
電話：+86 10 8288 2008 Eメール：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
唯一Y U mのああ（エディタ）HU Aは技術でない。3、X線でRDシャン低い地点情報産業基地H地区、北京100085 P. R.中国
Phone: +86 10 8288 2008 EMail: myz@huawei.com URI: www.huawei.com
電話：+86 10 8288 2008 Eメール：myz@huawei.com URI：www.huawei.com
Joseph Salowey (editor) Cisco Systems, Inc. 2901 3rd. Ave Seattle, WA 98121 USA
ジョセフSalowey（エディタ）シスコ・システムズ・インク2901年第3回。アベニューシアトル、WA 98121 USA
EMail: jsalowey@cisco.com
メールアドレス：jsalowey@cisco.com