Syslog Working Group F. Miao, Ed.
Internet-Draft Y. Ma, Ed.
Intended status: Standards Track Huawei Technologies
Expires: December 20, 2008 J. Salowey, Ed.
Cisco Systems, Inc.
June 18, 2008
TLS Transport Mapping for Syslog
draft-ietf-syslog-transport-tls-13.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 20, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
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.
Miao, et al. Expires December 20, 2008 [Page 1]
Internet-Draft TLS Transport Mapping for Syslog June 2008
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 . . . . . . . . . . . . 9
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . . 12
Appendix A. Changes from -12 . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 14
Miao, et al. Expires December 20, 2008 [Page 2]
Internet-Draft TLS Transport Mapping for Syslog June 2008
1. Introduction
This document describes the use of Transport Layer Security (TLS
[I-D.ietf-tls-rfc4346-bis]) to provide a secure connection for the
transport of syslog [I-D.ietf-syslog-protocol] messages. This
document describes the security threats to syslog and how TLS can be
used to counter such threats.
1.1. Terminology
The following definitions are used in this document:
o An "originator" generates syslog content to be carried in a
message.
o A "collector" gathers syslog content for further analysis.
o A "relay" forwards messages, accepting messages from originators
or other relays, and sending them to collectors or other relays.
o A "transport sender" passes syslog messages to a specific
transport protocol.
o A "transport receiver" takes syslog messages from a specific
transport protocol.
o A "TLS client" is an application that can initiate a TLS
connection by sending a Client Hello to a peer.
o A "TLS server" is an application that can receive a Client Hello
from a peer and reply with a Server 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].
2. Security Requirements for Syslog
Syslog messages may transit several hops to arrive at the intended
collector. Some intermediary networks may not be trusted by the
originator, relay, or receiver because the network is in a different
security domain or at a different security level from the originator,
relay, or collector. Another security concern is that the
originator, relay, or receiver itself is in an insecure network.
There are several threats to be addressed for syslog security. The
primary threats are:
Miao, et al. Expires December 20, 2008 [Page 3]
Internet-Draft TLS Transport Mapping for Syslog June 2008
o 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.
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 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.
The secondary threat is:
o 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.
The following threats are deemed to be of lesser importance for
syslog, and are not addressed in this document:
o Denial of Service
o Traffic Analysis
3. Using TLS to Secure Syslog
TLS can be used as a secure transport to counter all the primary
threats to syslog described above:
o Confidentiality to counter disclosure of the message contents;
o Integrity checking to counter modifications to a message on a hop-
by-hop basis;
o Server or mutual authentication to counter masquerade.
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
Miao, et al. Expires December 20, 2008 [Page 4]
Internet-Draft TLS Transport Mapping for Syslog June 2008
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,
[I-D.ietf-syslog-sign] can be used.
4. Protocol Elements
4.1. Port Assignment
A syslog transport sender is always a TLS client and a transport
receiver is always a TLS server.
The TCP port NNN has been allocated as the default port for syslog
over TLS, as defined in this document.
Note to RFC Editor: please replace NNN with the IANA-assigned value,
and remove this note.
4.2. Initiation
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 typically uses certificates [RFC5280] to authenticate peers.
Implementations MUST support TLS 1.2 [I-D.ietf-tls-rfc4346-bis] 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.
4.2.1. Certificate-Based Authentication
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:
o 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
Miao, et al. Expires December 20, 2008 [Page 5]
Internet-Draft TLS Transport Mapping for Syslog June 2008
syslog transport sender and receiver (i.e., verifying that the
subject name represents an authorized party) are described in
Section 5. Certificate path validation is performed as defined in
[RFC5280]. This method is useful where there is a PKI deployment.
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.
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.
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.
4.2.2. Certificate Fingerprints
Both client and server implementations MUST make the certificate
fingerprints for their certificate available through a management
interface.
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 "SHA1" 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 64 characters. An example certificate
fingerprint is:
SHA1: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.
Miao, et al. Expires December 20, 2008 [Page 6]
Internet-Draft TLS Transport Mapping for Syslog June 2008
4.2.3. Cryptographic Level
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.
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.
4.3. Sending data
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 ABNF
[RFC5234] expression:
APPLICATION-DATA = 1*SYSLOG-FRAME
SYSLOG-FRAME = MSG-LEN SP SYSLOG-MSG
MSG-LEN = NONZERO-DIGIT *DIGIT
SP = %d32
NONZERO-DIGIT = %d49-57
DIGIT = %d48 / NONZERO-DIGIT
SYSLOG-MSG is defined in syslog [I-D.ietf-syslog-protocol] protocol.
4.3.1. Message Length
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.
Miao, et al. Expires December 20, 2008 [Page 7]
Internet-Draft TLS Transport Mapping for Syslog June 2008
4.4. Closure
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).
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.
5. Security Policies
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.
If the peer does not meet the requirements of the security policy,
the TLS handshake SHOULD be aborted with an appropriate TLS alert.
5.1. End-Entity Certificate Based Authorization
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.
Miao, et al. Expires December 20, 2008 [Page 8]
Internet-Draft TLS Transport Mapping for Syslog June 2008
5.2. Subject Name Authorization
Implementations MUST support specifying the authorized peers using
locally configured host names, MUST support certification path
validation [RFC5280] and matching the name with the certificate as
follows:
Implementations MUST support matching the locally configured name
against a SubjectAltName field with a type of dNSName and SHOULD
support checking the name against the Common Name portion of the
Subject Distinguished Name. If more than one identity is present in
the certificate, a match in any one of the set is considered
acceptable. Matching of host names is case-insensitive.
Implementations also MAY support wildcards in locally configured
names to match a range of values. For example, a "*" wildcard
character MAY be used as the left-most name component. In this case,
*.example.com would match a.example.com, foo.example.com, etc., but
would not match example.com. Using a wildcard for the entire host
name makes it possible to deploy trust-root-based authorization where
all credentials issued by a particular CA trust root are authorized.
Implementations MAY also support matching a locally configured
identifier against other parts of the certificate, such as the
SerialNumber portion of the Subject Distinguished Name, or a
SubjectAltName of type ipAddress. Implementations MAY support other
checks such as restrictions on the depth of a certificate chain.
5.3. Unauthenticated Transport Sender
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 Section 2. The
use of this policy is generally NOT RECOMMENDED for this reason.
5.4. Unauthenticated Transport Receiver
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
Miao, et al. Expires December 20, 2008 [Page 9]
Internet-Draft TLS Transport Mapping for Syslog June 2008
use of this policy is generally NOT RECOMMENDED for this reason.
5.5. Unauthenticated Transport Receiver and Sender
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.2 and 5.3). This policy does not protect
against any of the threats described in Section 2 and is therefore
NOT RECOMMENDED.
6. Security Considerations
This section describes security considerations in addition to those
in [I-D.ietf-tls-rfc4346-bis].
6.1. Authentication and Authorization Policies
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 Section 5.1 and Section 5.2. These are
the RECOMMENDED configurations for a default policy.
If the transport receiver does not authenticate the transport sender
it may accept data from an attacker. Unless it has another way of
authenticating the source of the data, the data should not be
trusted. This is especially important if the syslog data is going to
be used to detect and react to security incidents. The transport
receiver may also increase its vulnerability to denial of service,
resource consumption and other attacks if it does not authenticate
the transport sender. Because of the increased vulnerability to
attack, this type of configuration is NOT RECOMMENDED.
If the transport sender does not authenticate the syslog transport
receiver then it may send data to an attacker. This may disclose
sensitive data within the log information that is useful to an
attacker resulting in further compromises within the system. If a
transport sender is operated in this mode, the data sent SHOULD be
limited to data that is not valuable to an attacker. In practice
this is very difficult to achieve, so this type of configuration is
NOT RECOMMENDED.
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.
Miao, et al. Expires December 20, 2008 [Page 10]
Internet-Draft TLS Transport Mapping for Syslog June 2008
6.2. Name Validation
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.
6.3. Reliability
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.
7. IANA Considerations
7.1. Port Number
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.
8. Acknowledgments
Authors appreciate Eric Rescorla, Rainer Gerhards, Tom Petch, Anton
Okmianski, Balazs Scheidler, Bert Wijnen, Martin Scheutte, 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.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[I-D.ietf-syslog-protocol]
Miao, et al. Expires December 20, 2008 [Page 11]
Internet-Draft TLS Transport Mapping for Syslog June 2008
Gerhards, R., "The syslog Protocol",
draft-ietf-syslog-protocol-23 (work in progress),
September 2007.
[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.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[I-D.ietf-tls-rfc4346-bis]
Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", draft-ietf-tls-rfc4346-bis-10
(work in progress), March 2008.
9.2. Informative References
[I-D.ietf-syslog-sign]
Kelsey, J., "Signed syslog Messages",
draft-ietf-syslog-sign-23 (work in progress),
October 2007.
Appendix A. Changes from -12
Please remove in published RFC.
Section 3: Expanded note to include reference to Syslog Sign.
Section 4.2: Included mandatory to implement ciphersuites that
track future versions of the TLS
Section 4.2.1: Revised to certificate based authentication
mechanisms. authorization policy is covered in section 5.
Section 4.2.2: added to describe fingerprint format
Section 5: new security policies section
Security Considerations: added reference to TLS security
considerations, removed cipher suite section which was redundant
with TLS
Added redundancy and name validation to security considerations
section
Miao, et al. Expires December 20, 2008 [Page 12]
Internet-Draft TLS Transport Mapping for Syslog June 2008
Authors' Addresses
Fuyou Miao (editor)
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
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
Email: jsalowey@cisco.com
Miao, et al. Expires December 20, 2008 [Page 13]
Internet-Draft TLS Transport Mapping for Syslog June 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Miao, et al. Expires December 20, 2008 [Page 14]