One document matched: draft-ietf-syslog-transport-tls-14.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "http://xml.resource.org/authoring/rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc5280 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5280.xml">
<!ENTITY SYSLOG-PROTO SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-syslog-protocol.xml">
<!ENTITY ietf-syslog-sign SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-syslog-sign.xml">
<!ENTITY rfc3766 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3766.xml">
<!ENTITY rfc5234 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5234.xml">
<!ENTITY rfc4346 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4346.xml">
<!ENTITY rfc5246 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY rfc4572 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4572.xml">
<!ENTITY __reference.RFC.2818__eyo4wecx SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2818.xml">
<!ENTITY __reference.RFC.4033__eyo4xhtj SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4033.xml">
]>
<!-- may be omitted for very short documents -->
<?rfc toc="yes"?>
<?rfc sortrefs="no"?>
<?rfc symrefs="yes"?>
<!-- these two save paper: start new sections from the same page etc. -->
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<!-- other categories: bcp, exp, historic, std -->
<rfc category="std" docName="draft-ietf-syslog-transport-tls-14.txt"
ipr="full3978">
<front>
<title>TLS Transport Mapping for Syslog</title>
<author fullname="Fuyou Miao" initials="F." surname="Miao" role="editor">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>No. 3, Xinxi Rd</street>
<street>Shangdi Information Industry Base</street>
<city>Haidian District</city>
<region>Beijing</region>
<code>100085</code>
<country>P. R. China</country>
</postal>
<phone>+86 10 8288 2008</phone>
<email>miaofy@huawei.com</email>
<uri>www.huawei.com</uri>
</address>
</author>
<author fullname="Yuzhi Ma" initials="Y." surname="Ma" role="editor">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>No. 3, Xinxi Rd</street>
<street>Shangdi Information Industry Base</street>
<city>Haidian District</city>
<region>Beijing</region>
<code>100085</code>
<country>P. R. China</country>
</postal>
<phone>+86 10 8288 2008</phone>
<email>myz@huawei.com</email>
<uri>www.huawei.com</uri>
</address>
</author>
<author fullname="Joseph Salowey" initials="J" surname="Salowey" role="editor">
<organization> Cisco Systems, Inc. </organization>
<address>
<postal>
<street>2901 3rd. Ave</street>
<city>Seattle</city>
<code>98121</code>
<region>WA</region>
<country>USA</country>
</postal>
<email> jsalowey@cisco.com </email>
</address>
</author>
<date month="September" year="2008" />
<area>Security</area>
<workgroup>Syslog Working Group</workgroup>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>Syslog TLS Transport Security</keyword>
<keyword>Internet-Draft</keyword>
<keyword>XML</keyword>
<keyword>Extensible Markup Language</keyword>
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>This document describes the use of Transport Layer Security (<xref
target="RFC5246">TLS</xref>) to provide a secure connection for the
transport of <xref target="I-D.ietf-syslog-protocol">syslog</xref>
messages. This document describes the security threats to syslog and how
TLS can be used to counter such threats.</t>
<section title="Terminology">
<t>The following definitions are used in this document: <list
style="symbols">
<t>An "originator" generates syslog content to be carried in a
message.</t>
<t>A "collector" gathers syslog content for further analysis.</t>
<t>A "relay" forwards messages, accepting messages from
originators or other relays, and sending them to collectors or
other relays.</t>
<t>A "transport sender" passes syslog messages to a specific
transport protocol.</t>
<t>A "transport receiver" takes syslog messages from a specific
transport protocol.</t>
<t>A "TLS client" is an application that can initiate a TLS
connection by sending a Client Hello to a server.</t>
<t>A "TLS server" is an application that can receive a Client Hello
from a client and reply with a Server Hello.</t>
</list></t>
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</section>
</section>
<section title="Security Requirements for Syslog" anchor="reqs">
<t>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.</t>
<t>There are several threats to be addressed for syslog security. The
primary threats are: <list style="symbols">
<t>Masquerade. An unauthorized transport sender may send messages to
a legitimate transport receiver, or an unauthorized transport
receiver tries to deceive a legitimate transport sender into sending
syslog messages to it.</t>
<t>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.</t>
<t>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.</t>
</list></t>
<t>The secondary threat is: <list style="symbols">
<t>Message stream modification. An attacker may delete one or more
syslog message from a series of messages, replay a message, or alter
the delivery sequence. The syslog protocol itself is not based on
message order, but 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.</t>
</list></t>
<t>The following threats are deemed to be of lesser importance for
syslog, and are not addressed in this document: <list style="symbols">
<t>Denial of Service</t>
<t>Traffic Analysis</t>
</list></t>
</section>
<section title="Using TLS to Secure Syslog">
<t>TLS can be used as a secure transport to counter all the primary
threats to syslog described above: <list style="symbols">
<t>Confidentiality to counter disclosure of the message
contents;</t>
<t>Integrity checking to counter modifications to a message on a
hop-by-hop basis;</t>
<t>Server or mutual authentication to counter masquerade.</t>
</list>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, <xref target="I-D.ietf-syslog-sign" /> can be used.</t>
</section>
<section title="Protocol Elements">
<section title="Port Assignment">
<t>A syslog transport sender is always a TLS client and a transport
receiver is always a TLS server.</t>
<t>The TCP port NNN has been allocated as the default port for syslog
over TLS, as defined in this document.</t>
<t>Note to RFC Editor: please replace NNN with the IANA-assigned
value, and remove this note.</t>
</section>
<section title="Initiation">
<t>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.</t>
<t>TLS typically uses <xref target="RFC5280">certificates</xref> to authenticate
peers. Implementations MUST support
<xref target="RFC5246">TLS 1.2</xref> 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.</t>
<section title="Certificate-Based Authentication" anchor="certauth">
<t>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:</t>
<list style="symbols">
<t>Certification path validation: The TLS peer is configured with one
or more trust anchors (typically root CA 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 <xref target="secpol" />. Certificate path
validation is performed as defined in
<xref target="RFC5280" />. This method is
useful where there is a PKI deployment.</t>
<t>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 <xref target="finger" />
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. </t>
</list>
<t>Both transport receiver and transport sender implementations MUST provide a 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.</t>
<t> 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.</t>
</section>
<section title="Certificate Fingerprints" anchor="finger">
<t>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 <xref target="RFC4572"/>. </t>
<t>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:
</t>
<list>
<t>sha-1:E1:2D:53:2B:7C:6B:8A:29:A2:76:C8:64:36:0B:08:4B:7A:F1:9E:9D</t>
</list>
<t>During validation the hash is extracted from the fingerprint and compared against the hash calculated over the received certificate.</t>
</section>
<section title="Cryptographic Level">
<t>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.</t>
<t>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 requirement of the requested session to make sure that the
resumed session provides proper security.</t>
</section>
</section>
<section title="Sending data">
<t>All syslog messages MUST be sent as TLS "application data". It is
possible that multiple syslog messages be contained in one TLS record,
or that a syslog message be transferred in multiple TLS records. The
application data is defined with the following <xref
target="RFC5234">ABNF</xref> expression:</t>
<t>APPLICATION-DATA = 1*SYSLOG-FRAME</t>
<t>SYSLOG-FRAME = MSG-LEN SP SYSLOG-MSG</t>
<t>MSG-LEN = NONZERO-DIGIT *DIGIT</t>
<t>SP = %d32</t>
<t>NONZERO-DIGIT = %d49-57</t>
<t>DIGIT = %d48 / NONZERO-DIGIT</t>
<t>SYSLOG-MSG is defined in <xref
target="I-D.ietf-syslog-protocol">syslog</xref> protocol.</t>
<section title="Message Length">
<t>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 receiver SHOULD be able to process
messages with lengths up to and including 8192 octets.</t>
</section>
</section>
<section title="Closure">
<t> 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).</t>
<t>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. </t>
</section>
</section>
<section title="Security Policies" anchor="secpol">
<t>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. </t>
<t>If the peer does not meet the requirements of the security
policy, the TLS handshake MUST be aborted with an appropriate
TLS alert.</t>
<section title="End-Entity Certificate Based Authorization" anchor="eeauth" >
<t>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.</t>
<t> Implementations MUST support specifying the authorized peers using
certificate fingerprints, as described in <xref target="certauth" /> and <xref target="finger" />.</t>
</section>
<section title="Subject Name Authorization" anchor="recpol">
<t>Implementations MUST support certification path validation <xref target="RFC5280"/>.
In addition they MUST support specifying the authorized peers using
locally configured host names and matching the name against the
certificate as follows.</t>
<list style="symbols">
<t>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.</t>
<t>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), and then 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.</t>
<t>Locally configured names MAY contain the wildcard character to match
a range of values. The types of wildcards supported MAY be more
flexible than that which is allowed in subject names to make 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.</t>
<t>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 <xref target="RFC5280"/>.</t>
<t>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 <xref target="RFC5280"/>, Section 4.2.1.6. A match occurs if
this octet string is equal to the value of iPAddress in the
subjectAltName extension.</t>
</list>
</section>
<section title="Unauthenticated Transport Sender">
<t>
In some environments, the authenticity of syslog data is not important or it 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 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 <xref target="reqs" />. The use of this policy is generally NOT RECOMMENDED for this reason. </t>
</section>
<section title="Unauthenticated Transport Receiver">
<t>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 <xref target="reqs" />, leaving the data sent vulnerable to disclosure and modification. The use of this policy is generally NOT RECOMMENDED for this reason.</t>
</section>
<section title="Unauthenticated Transport Receiver and Sender">
<t>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 <xref target="reqs" /> and is therefore NOT RECOMMENDED.</t>
</section>
</section>
<section title="Security Considerations">
<t>This section describes security considerations in addition to those in <xref target="RFC5246" />. </t>
<section title="Authentication and Authorization Policies">
<t>
<xref target="secpol" /> discusses various security policies that may be deployed. The threats in <xref target="reqs" /> are mitigated only if both the transport sender and transport receiver are properly authenticated and authorized, as described in <xref target="eeauth" /> and <xref target="recpol" />. These are the RECOMMENDED configurations for a default policy.</t>
<t>
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. </t>
<t>
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.</t>
<t>
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.</t>
</section>
<section title="Name Validation">
<t>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 some other means such as DNS lookup since this introduces additional security vulnerabilities. </t>
</section>
<section title="Reliability">
<t> 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. </t>
</section>
</section>
<section title="IANA Considerations">
<section title="Port Number">
<t>IANA is requested to assign a TCP port number in the "Registered
Port Numbers" range with the name "syslog-tls". This port will
be the default port for syslog over TLS, as defined in this
document.</t>
</section>
</section>
<section title="Acknowledgments">
<t>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
appreciate 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.</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&SYSLOG-PROTO;
&rfc5280;
&rfc5234;
&rfc5246;
</references>
<references title="Informative References">
&ietf-syslog-sign;
&rfc4572;
</references>
<section title="Changes from -12">
<t>Please remove in published RFC.</t>
<list>
<t>Section 3: Expanded note to include reference to Syslog Sign.</t>
<t>Section 4.2: Included mandatory to implement ciphersuites that track future versions of the TLS</t>
<t>Section 4.2.1: Revised to certificate based authentication mechanisms. authorization policy is covered in section 5.</t>
<t>Section 4.2.2: added to describe fingerprint format</t>
<t>Section 5: new security policies section </t>
<t>Security Considerations: added reference to TLS security considerations, removed cipher suite section which was redundant with TLS</t>
<t>Added redundancy and name validation to security considerations section</t>
</list>
</section>
<section title="Changes from -13" >
<t>Please remove in published RFC.</t>
<list>
<t>Section 1.1: Cleaned up definition of TLS client and TLS server</t>
<t>Section 4.2.2: Changed certificate fingerprint section to reference hash registry (changed "SHA-1" to "sha-1"</t>
<t>Section 4.4: Clarified transport receiver and transport sender language. Removed last sentence on sending pending data after close.</t>
<t>Section 5: changed SHOULD be aborted to MUST be aborted</t>
<t>Section 5.2: replaced text with bullets enumerating requirements</t>
<t>Section 5.5: Fixed section references</t>
<t>Section 7.1: change IANA assignment to registered port</t>
<t>Section 8: Fixed the spelling of Martin's name</t>
</list>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 16:29:54 |