One document matched: draft-ietf-syslog-transport-tls-11.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 SYSLOG-PROTO SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-syslog-protocol.xml">
<!ENTITY rfc3280 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3280.xml">
<!ENTITY rfc3766 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3766.xml">
<!ENTITY rfc4234 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4234.xml">
<!ENTITY __reference.RFC.4346__ev62ungb SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4346.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"?>
<!-- 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-11.txt"
ipr="full3978">
<front>
<title>TLS Transport Mapping for Syslog</title>
<author fullname="Fuyou Miao" initials="F." surname="Miao">
<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">
<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>
<date year="2007" />
<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="RFC4346">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 peer.</t>
<t>A "TLS server" is an application that can receive a Client
Hello from a peer 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">
<t>syslog messages may pass several hops to arrive at the intended
collector. Some intermediary networks may not be trusted by the
originator, relay, receiver, or all 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="TLS to Secure Syslog">
<t>TLS can be used as a secure transport to counter all the primary
threats to syslog described in section 2: <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 in a
hop-by-hop manner, the threat of end-to-end message stream modification
is not addressed in this document.</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 uses <xref target="RFC3280">certificates</xref> to authenticate
peers. Authentication in this specification means that the recipient
of a certificate must actually validate the certificate rather than
just accept a certificate. Validation includes constructing a
certificate path to one of the configured trust anchors and validating
that path, and the identity check against the rules defined in section
4.2.1 and section 4.2.2.</t>
<section title="Server Identity">
<t>A procedure similar to <xref target="RFC2818">RFC2818</xref> is
used to check the server's identity in the certificate.</t>
<t>In general, the client is configured with the hostname or IP
address of the TLS server. As a consequence, the hostname or IP
address for the server is known to the client. If the hostname (or
IP address) is available, the client MUST check it against the
server's identity as presented in the server's certificate message,
in order to prevent man-in-the-middle attacks.</t>
<t>If the client has external information as to the expected
identity of the server, the hostname (or IP address) check MAY be
omitted. (For instance, a client may be connecting to a machine
whose address and hostname are dynamic but the client knows the
certificate that the server will present.) In such cases, it is
important to narrow the scope of acceptable certificates as much as
possible in order to prevent man-in-the-middle attacks. In special
cases, it may be appropriate for the client to simply ignore the
server's identity, but it must be understood that this leaves the
connection open to active attack.</t>
<t>If a subjectAltName extension of type dNSName is present, that
MUST be used as the identity. Otherwise, the (most specific) Common
Name field in the Subject field of the certificate MUST be used.
Although the use of the Common Name is current practice, it is
deprecated and Certification Authorities are encouraged to use the
dNSName instead.</t>
<t>Matching is performed using the matching rules specified by <xref
target="RFC3280">RFC3280</xref>. Names may contain the wildcard
character * which is considered to match any single domain name
component or component fragment. E.g., *.a.com matches foo.a.com but
not bar.foo.a.com. f*.com matches foo.com but not bar.com. If the
client is configured with IP address of the server, the hostname
should be got first through a trusted mechanism such as a
preconfigured hosts table or <xref
target="RFC4033">DNSSEC</xref>.</t>
<t>If the iPAddress subjectAltName is present in the certificate, it
must exactly match the IP address configured or resolved from the
configured hostname through a trusted mechanism such as a
preconfigured hosts table or DNSSEC.</t>
<t>It is recommended to use dNSName in the certificate rather than
any other type subjectAltName for certificate verification, such as
ipAddress. If more than one identity of a given type is presented in
the certificate (e.g., more than one dNSName name), a match in any
one of the set is considered acceptable.</t>
<t>If the hostname does not match the identity in the certificate,
clients SHOULD log the error in some form or another (see next
paragraph), and SHOULD terminate the connection with a bad
certificate error. Clients MAY provide a configuration setting that
disables this check but MUST enable it by default.</t>
<t>The application developer must take some care to consider the
case when, for whatever reason, there is a problem with
authenticating the other end of the connection. Since this problem
will prevent log messages from being transmitted, each device having
this problem should use whatever means are available to inform the
administrator of the problem. This may include producing an error
code on a console, returning an error to a user (if there is one),
or writing a file to disk, being mindful that such writes should be
rate limited in the case of attacks.</t>
</section>
<section title="Client Identity">
<t>If a server authenticates a client and the client presents a
certificate to the server, the server MUST validate the certificate.
Validation includes constructing a certificate path to one of the
configured trust anchors and validating that path. However, identity
check is not required even if subjectAltName is presented in the
certificate.</t>
<t>The subjectAltName may be the host name, IP address, MAC, device
ID, etc. SubjectAltName is not necessarily unique for different
certificates. For example, certificates for some types of printer
might use the same subjectAltName.</t>
<t>A client certificate may be issued by an operator when a
device/application is being provisioned, or by a vendor when the
device/application is manufactured. This document does not define
how the client certificate is issued.</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="RFC4234">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 tranport 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 TLS client 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
client MAY choose to not wait for the server's close_notify alert and
simply close the connection, thus generating an incomplete close on
the server side. Once the server gets a close_notify from the client,
it MUST reply with a close_notify unless it becomes aware that the
connection has already been closed by the client (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 server MAY close the
connection. The server MUST attempt to initiate an exchange of
close_notify alerts with the client before closing the connection.
Servers 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 client side. When the client has received the
close_notify alert from the server and still has pending data to send,
it SHOULD send the pending data before sending the close_notify
alert.</t>
</section>
</section>
<section title="Security Considerations">
<section title="Authentication and Certificates">
<t>In security sensitive environments, it is recommended that mutual
authentication be deployed as that will prevent masquerade attacks,
modification of the messages, and disclosure of the contents of the
messages. Mutual authentication means the TLS client and server are
provisioned with necessary trust roots and must perform certificate
validation. </t>
<t>In security insensitive environments, the client or server may
forego certificate validation. Note that this opens up the protocol
for an active man-in-the middle attack if none of the parties are
authenticated against trust anchors. It is recommended that server is
configured with certificate, and the client validates the certificate
against provisioned trust anchors. If a server does not have a
certificate and key/pair configured then it must generate a key pair
and a self-signed certificate to make the protocol work. If the syslog
client does not have a certificate then it may generate a self signed
certificate. </t>
<t>The server MUST be implemented to support certificate and
certificate generation, and certificate validation MUST be implemented
for all clients. The Syslog client SHOULD be implementated to support
certificate and certificate generation, and certificate validation
SHOULD be inplemented for Syslog server. In order to provide better
protection for future session the client and server MAY cache the
certificate presented by its peer so it can compare the certificate
with what is presented in subsequent connections. Note that generated
certificates should be persistent in this case.</t>
<t>TLS authentication and the distribution of keys is based on
certificates and asymmetric cryptography. This makes TLS transport
more expensive than non-TLS plain transport. An attacker may
initialize many TLS connections to a receiver as a denial of service
attack. Since a receiver may act upon received data, for syslog over
TLS, it is recommended that the server authenticate the client to
ensure that information received is authentic.</t>
</section>
<section title="Cipher Suites">
<t>This specification specifies the following cipher suite required
for all compliant implementation for minimum interoperability
purposes:</t>
<t>TLS_RSA_WITH_AES_128_CBC_SHA</t>
<t>Operators MAY choose to disable older/weaker cipher suites for TLS
despite the tradeoff of interoperability, for example, if the cipher
suite specified in the specification is found weak in the future. This
allows the future update of the specification to change
mandatory-to-implement cipher requirement for interoperability. This
also allows the TLS community to change its recommendations, and
operators to follow those recommendations.</t>
<t>The implementers and deployers should be aware of the strengths of
the public keys algorithm in the suite for exchanging symmetric keys,
which is elaborated in <xref target="RFC3766">BCP86</xref>. The
implementers and deployers should also be aware of the latest TLS and
other IETF cryptography standards including BCP86.</t>
</section>
</section>
<section title="IANA Considerations">
<section title="Port Number">
<t>IANA is requested to assign a TCP port number in the range 1..1023
in the http://www.iana.org/assignments/port-numbers registry which
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, and Chris Lonvick 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.</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&SYSLOG-PROTO;
&rfc3280;
&rfc3766;
&rfc4234;
&__reference.RFC.4346__ev62ungb;
</references>
<references title="Informative References">
&__reference.RFC.2818__eyo4wecx;
&__reference.RFC.4033__eyo4xhtj;
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-23 16:29:53 |