Syslog Working Group F. Miao
Internet-Draft Y. Ma
Intended status: Standards Track Huawei Technologies
Expires: May 20, 2008 November 17, 2007
TLS Transport Mapping for Syslog
draft-ietf-syslog-transport-tls-11.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 May 20, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
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 & Ma Expires May 20, 2008 [Page 1]
Internet-Draft TLS Transport Mapping for Syslog November 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Security Requirements for Syslog . . . . . . . . . . . . . . . 3
3. TLS to Secure Syslog . . . . . . . . . . . . . . . . . . . . . 4
4. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Port Assignment . . . . . . . . . . . . . . . . . . . . . 5
4.2. Initiation . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2.1. Server Identity . . . . . . . . . . . . . . . . . . . 5
4.2.2. Client Identity . . . . . . . . . . . . . . . . . . . 7
4.2.3. Cryptographic Level . . . . . . . . . . . . . . . . . 7
4.3. Sending data . . . . . . . . . . . . . . . . . . . . . . . 7
4.3.1. Message Length . . . . . . . . . . . . . . . . . . . . 8
4.4. Closure . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5.1. Authentication and Certificates . . . . . . . . . . . . . 8
5.2. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6.1. Port Number . . . . . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . . . 12
Miao & Ma Expires May 20, 2008 [Page 2]
Internet-Draft TLS Transport Mapping for Syslog November 2007
1. Introduction
This document describes the use of Transport Layer Security (TLS [6])
to provide a secure connection for the transport of syslog [2]
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 [1].
2. Security Requirements for Syslog
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.
There are several threats to be addressed for syslog security. The
primary threats are:
Miao & Ma Expires May 20, 2008 [Page 3]
Internet-Draft TLS Transport Mapping for Syslog November 2007
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. TLS to Secure Syslog
TLS can be used as a secure transport to counter all the primary
threats to syslog described in section 2:
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 in a hop-
by-hop manner, the threat of end-to-end message stream modification
Miao & Ma Expires May 20, 2008 [Page 4]
Internet-Draft TLS Transport Mapping for Syslog November 2007
is not addressed in this document.
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 uses certificates [3] 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.
4.2.1. Server Identity
A procedure similar to RFC2818 [7] is used to check the server's
identity in the certificate.
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.
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
Miao & Ma Expires May 20, 2008 [Page 5]
Internet-Draft TLS Transport Mapping for Syslog November 2007
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.
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.
Matching is performed using the matching rules specified by RFC3280
[3]. 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 DNSSEC [8].
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.
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.
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.
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.
Miao & Ma Expires May 20, 2008 [Page 6]
Internet-Draft TLS Transport Mapping for Syslog November 2007
4.2.2. Client Identity
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.
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.
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.
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 [5]
expression:
APPLICATION-DATA = 1*SYSLOG-FRAME
SYSLOG-FRAME = MSG-LEN SP SYSLOG-MSG
MSG-LEN = NONZERO-DIGIT *DIGIT
SP = %d32
Miao & Ma Expires May 20, 2008 [Page 7]
Internet-Draft TLS Transport Mapping for Syslog November 2007
NONZERO-DIGIT = %d49-57
DIGIT = %d48 / NONZERO-DIGIT
SYSLOG-MSG is defined in syslog [2] protocol.
4.3.1. Message Length
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.
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 Considerations
5.1. Authentication and Certificates
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
Miao & Ma Expires May 20, 2008 [Page 8]
Internet-Draft TLS Transport Mapping for Syslog November 2007
messages. Mutual authentication means the TLS client and server are
provisioned with necessary trust roots and must perform certificate
validation.
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.
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.
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.
5.2. Cipher Suites
This specification specifies the following cipher suite required for
all compliant implementation for minimum interoperability purposes:
TLS_RSA_WITH_AES_128_CBC_SHA
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.
Miao & Ma Expires May 20, 2008 [Page 9]
Internet-Draft TLS Transport Mapping for Syslog November 2007
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 BCP86 [4]. The implementers and deployers
should also be aware of the latest TLS and other IETF cryptography
standards including BCP86.
6. IANA Considerations
6.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.
7. Acknowledgments
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.
8. References
8.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Gerhards, R., "The syslog Protocol",
draft-ietf-syslog-protocol-23 (work in progress),
September 2007.
[3] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509
Public Key Infrastructure Certificate and Certificate Revocation
List (CRL) Profile", RFC 3280, April 2002.
[4] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys
Used For Exchanging Symmetric Keys", BCP 86, RFC 3766,
April 2004.
[5] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
Miao & Ma Expires May 20, 2008 [Page 10]
Internet-Draft TLS Transport Mapping for Syslog November 2007
[6] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
Protocol Version 1.1", RFC 4346, April 2006.
8.2. Informative References
[7] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[8] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"DNS Security Introduction and Requirements", RFC 4033,
March 2005.
Authors' Addresses
Fuyou Miao
Huawei Technologies
No. 3, Xinxi Rd
Shangdi Information Industry Base
Haidian District, Beijing 100085
P. R. China
Phone: +86 10 8288 2008
Email: miaofy@huawei.com
URI: www.huawei.com
Yuzhi Ma
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
Miao & Ma Expires May 20, 2008 [Page 11]
Internet-Draft TLS Transport Mapping for Syslog November 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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 & Ma Expires May 20, 2008 [Page 12]
