Syslog Working Group F. Miao
Internet-Draft M. Yuzhi
Intended status: Informational Huawei Technologies
Expires: February 28, 2007 August 27, 2006
TLS Transport Mapping for SYSLOG
draft-ietf-syslog-transport-tls-03.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 February 28, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
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 & Yuzhi Expires February 28, 2007 [Page 1]
Internet-Draft TLS Transport Mapping for SYSLOG August 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Security Requirements for Syslog . . . . . . . . . . . . . . . 3
3. TLS Fundmentals . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. How TLS works . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Security Properties . . . . . . . . . . . . . . . . . . . 4
4. TLS to secure Syslog . . . . . . . . . . . . . . . . . . . . . 5
5. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Port Assignment . . . . . . . . . . . . . . . . . . . . . 5
5.2. Initiation . . . . . . . . . . . . . . . . . . . . . . . . 6
5.3. Sending data . . . . . . . . . . . . . . . . . . . . . . . 7
5.3.1. Frame Length . . . . . . . . . . . . . . . . . . . . . 7
5.3.2. Version . . . . . . . . . . . . . . . . . . . . . . . 7
5.4. Closure . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Security Consideration . . . . . . . . . . . . . . . . . . . . 8
6.1. Authentication . . . . . . . . . . . . . . . . . . . . . . 8
6.2. Generic Certificate . . . . . . . . . . . . . . . . . . . 8
7. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Port Number . . . . . . . . . . . . . . . . . . . . . . . 9
7.2. VERSION . . . . . . . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 11
Miao & Yuzhi Expires February 28, 2007 [Page 2]
Internet-Draft TLS Transport Mapping for SYSLOG August 2006
1. Introduction
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.
1.1. Terminology
The following definitions are used in this document:
o A sender is an application that can generate and send a Syslog [2]
message to another application.
o A receiver is an application that can receive a Syslog message.
o A relay is an application that can receive syslog messages and
forward them to another receiver.
o A collector is an application that can receive messages but does
not relay them to any other receiver.
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
receiver. Some intermediary networks may not be trusted by the
sender/relay, receiver, or all because the network is in a different
security domain or at a different security level from the receiver,
relay, or sender. Another security concern is that the sender/relay,
or receiver itself is in an insecure network.
There are several threats to be addressed for Syslog security. The
primary threats are:
o Masquerade. An unauthorized sender/relay may send messages to a
legitimate receiver, or an unauthorized receiver tries to deceive
a legitimate sender/relay into sending Syslog messages to it.
Miao & Yuzhi Expires February 28, 2007 [Page 3]
Internet-Draft TLS Transport Mapping for SYSLOG August 2006
o Modification. An attacker between the sender/relay and receiver
may modify an in-transit Syslog message from the sender/relay and
then forward the message to receiver. Such modification may make
the receiver misunderstand the message or cause the receiver to
behave in undesirable ways.
o Disclosure. An unauthorized entity may examine the content 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 a Syslog
message from a series of messages, replay a message or alter the
delivery sequence. 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 Fundmentals
3.1. How TLS works
TLS [4] establishes a private end-to-end connection, optionally
including strong mutual authentication, using a variety of
cryptosystems. Initially, a handshake phase uses three subprotocols
to set up a record layer, authenticate endpoints, set parameters, and
report errors. Then, there is an ongoing layered record protocol
that handles encryption and message integrity for the remainder of
the connection. An application data protocol, such as Syslog, is
layered on the record protocol.
3.2. Security Properties
The TLS record protocol is used to encapsulate various higher level
protocols. It provides connection security with confidentiality,
integrity, authentication, and replay prevention.
Miao & Yuzhi Expires February 28, 2007 [Page 4]
Internet-Draft TLS Transport Mapping for SYSLOG August 2006
Confidentiality is provided using symmetric cryptography for data
encryption. TLS supports both stream cipher and block cipher. The
key for encryption is derived from a secret established by the
handshake protocol. When there is an eavesdropper in the middle, the
secret is kept private if at least one session identifier is
authenticated during hanshake.
Integrity is provided by using a message authentication code to check
the integrity of a message. Modification without the appropriate key
is detectable.
Authentication is provided by a handshake protocol. The peer's
identity is authenticated using asymmetric cryptography.
Replay prevention is provided by using a Sequence Number in each TLS
record that is used to detect a missing record, the replay of a
record, or alteration of the delivery sequence.
4. TLS to secure Syslog
TLS can be used as a secure transport to counter all the primary and
secondary threats to Syslog described in section 2:
o Confidentiality to counter disclosure of the message contents
o Integrity check to counter modifications to a message
o Peer authentication to counter masquerade
o Sequence number along with integrity check to counter message
stream modification
The security service is also applicable to BSD Syslog defined in
RFC3164 [7]. But, it is not ensured that the protocol specification
defined in this document is applicable to BSD Syslog.
5. Protocol Elements
5.1. Port Assignment
A Syslog sender/relay is always a TLS client and a Syslog 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.
Miao & Yuzhi Expires February 28, 2007 [Page 5]
Internet-Draft TLS Transport Mapping for SYSLOG August 2006
Note to RFC Editor: please replace NNN with the IANA-assigned value,
and remove this note.
5.2. Initiation
The sender/relay should initiate a connection to the receiver and
then send the TLS Client Hello to begin the TLS handshake. When the
TLS handshake has finished the sender/relay may then send the first
Syslog message.
TLS uses certificate [6] to authenticate the peers. When a sender/
relay authenticates a receiver it MUST validate the certificate. It
SHOULD check the common name(CN) of the certificate against the host
name of the receiver if it has knowledge of a common name/host name
mapping. If the common name does not match the host name, the
sender/relay SHOULD send an "access_denied" error alert using the TLS
alert protocol to terminate the handshake, and then it SHOULD close
the connection.
When a receiver authenticates a sender/relay, the receiver MUST
validate the certificate. A sender's (or relay's) certificate may
be:
o A unique certificate, which is issued to a host and whose Common
Name may be host name, IP address, MAC, or device ID.
o A generic certificate, which is issued to a class of application
or device. For example, all cable modems from a vendor may be
issued the same generic certificate.
A sender/relay 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 sender/relay certificate is issued.
Syslog applications SHOULD be implemented in a manner that permits
administrators to select the cryptographic level they desire. It
SHOULD be an administrator decision, as a matter of local policy,
what security level (e.g. cryptographic algorithms and length of
keys) is required.
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 security
requirement of requested session to make sure the resumed session
provides proper security.
Miao & Yuzhi Expires February 28, 2007 [Page 6]
Internet-Draft TLS Transport Mapping for SYSLOG August 2006
5.3. Sending data
All Syslog messages MUST be sent as TLS "application data". It is
possible that there are multiple Syslog messages in one TLS record,
or a Syslog message is transferred in multiple TLS record. The
application data is defined with the following ABNF [3] expression:
APPLICATION-DATA = 1*SYSLOG-FRAME
SYSLOG-FRAME = FRAME-HEADER SP SYSLOG-MSG
FRAME-HEADER = VERSION SP FRAME-LEN
VERSION = NONZERO-DIGIT 0*DIGIT
FRAME-LEN = NONZERO-DIGIT 0*DIGIT
SP = %d32
DIGIT = %d48 / NONZERO-DIGIT
NONZERO-DIGIT = %d49-57
SYSLOG-MSG is defined in Syslog [2] protocol.
5.3.1. Frame Length
The frame length is the octet count of a SYSLOG frame including the
FRAME-HEADER and SP parts. A receiver MUST use the frame length
field to delimit a syslog message. There is not upper limit for a
frame length per se. However, in order to establish a baseline for
interoperability, the specification requires that a receiver MUST be
able to process frame with size up to and including 2048 octects. It
SHOULD be able to reveive frame with size up to and including 8192
octects.
5.3.2. Version
The version is to identify the version of the TLS transport mapping
for Syslog, and the version is 1.
5.4. Closure
A Syslog sender/relay MUST close the associated TLS connection if the
connection is not expected to deliver Syslog message later. It MUST
send a TLS closure_notify alert before closing the connection. A
sender/relay MAY choose not to wait for the receiver's closure_notify
alert and simply close the connection, thus generating an incomplete
Miao & Yuzhi Expires February 28, 2007 [Page 7]
Internet-Draft TLS Transport Mapping for SYSLOG August 2006
close on the receiver side. Once the receiver gets closure_notify
from the sender/relay, it MUST reply with a closure_notify unless it
becomes aware that the connection has already been closed by the
sender/relay(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 receiver MAY close a
connection. The receiver MUST attempt to initiate an exchange of
closure_notify alerts with the sender/relay before closing the
connection. Receivers that are unprepared to receive any more data
MAY close the connection after sending the closure_notify alert, thus
generating an incomplete close on the sender/relay side. When the
sender/relay has received the closure_notify alert from the receiver
and still has pending data to send, it SHOULD send the pending data
before sending the closure_notify alert.
6. Security Consideration
6.1. Authentication
TLS supports three authentication modes: authentication of both
parties, server authentication with an unauthenticated client, and
total anonymity.
TLS authentication and the establishment of secrets is based on
certificates and asymmetric cryptography. This makes TLS transport
much 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,the receiver SHOULD authenticate the sender/relay to ensure that
information received is authentic.
When confidentiality is a concern, a sender/relay MUST authenticate
the receiver to make sure it is talking to the right peer.
6.2. Generic Certificate
When a certificate is issued to a class of device or application, the
certificate may be shared by multiple hosts. Multiple hosts know the
private key of the certificate. When the certificate in one host is
compromised, then the certificate for all hosts that share the
certificate is compromised. An attacker may impersonate a legitimate
sender to send Syslog message to a receiver.
Miao & Yuzhi Expires February 28, 2007 [Page 8]
Internet-Draft TLS Transport Mapping for SYSLOG August 2006
7. IANA Consideration
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.
7.2. VERSION
IANA must maintain a registry of VERSION values as described in
Section 5.3.2. Version numbers MUST be incremented for any new
Syslog TLS transport mapping specification that changes any part of
the frame or other parts. Changes include addition or removal of
fields or a change of syntax or semantics of existing fields.
VERSION numbers must be registered via the Standards Action method as
described in RFC2434 [5]. IANA must register the VERSIONs shown
below.
VERSION FORMAT
1 According to this specification
8. Acknowledgments
Authors appreciate Anton Okmianski, Rainer Gerhards, Balazs Scheidler
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
author would like to acknowledge David Harrington for his detailed
reviews of the content and grammar of the document.
9. References
9.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-17 (work in progress), June 2006.
[3] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
Miao & Yuzhi Expires February 28, 2007 [Page 9]
Internet-Draft TLS Transport Mapping for SYSLOG August 2006
[4] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[6] 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.
9.2. Informative References
[7] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, August 2001.
Authors' Addresses
Miao Fuyou
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
Ma Yuzhi
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 & Yuzhi Expires February 28, 2007 [Page 10]
Internet-Draft TLS Transport Mapping for SYSLOG August 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
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 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 & Yuzhi Expires February 28, 2007 [Page 11]
