Syslog Working Group                                             F. Miao
Internet-Draft                                                  M. Yuzhi
Intended status: Standards Track                     Huawei Technologies
Expires: October 25, 2007                                 April 23, 2007

                    TLS Transport Mapping for Syslog

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on October 25, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).


   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 October 25, 2007                [Page 1]

Internet-Draft      TLS Transport Mapping for Syslog          April 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  . . . . . . . . . . . . . . . . . . .  6
       4.2.3.  Cryptographic Level  . . . . . . . . . . . . . . . . .  7
     4.3.  Sending data . . . . . . . . . . . . . . . . . . . . . . .  7
       4.3.1.  Message Length . . . . . . . . . . . . . . . . . . . .  7
     4.4.  Closure  . . . . . . . . . . . . . . . . . . . . . . . . .  8
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
     5.1.  Authentication . . . . . . . . . . . . . . . . . . . . . .  8
     5.2.  Cipher Suites  . . . . . . . . . . . . . . . . . . . . . .  9
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
     6.1.  Port Number  . . . . . . . . . . . . . . . . . . . . . . .  9
   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  9
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     8.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
   Intellectual Property and Copyright Statements . . . . . . . . . . 11

Miao & Yuzhi            Expires October 25, 2007                [Page 2]

Internet-Draft      TLS Transport Mapping for Syslog          April 2007

1.  Introduction

   This document describes the use of Transport Layer Security (TLS [6])
   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",
   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 October 25, 2007                [Page 3]

Internet-Draft      TLS Transport Mapping for Syslog          April 2007

   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

   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 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 check to counter modifications to a message on a hop-to-
      hop basis;

   o  Server or mutual authentication to counter masquerade.

   Note: Secure transport (i.e.  TLS) only secures syslog in a hop by
   hop manner, end to end message stream modificationis threat is not
   addressed in this document.

Miao & Yuzhi            Expires October 25, 2007                [Page 4]

Internet-Draft      TLS Transport Mapping for Syslog          April 2007

4.  Protocol Elements

4.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.

   Note to RFC Editor: please replace NNN with the IANA-assigned value,
   and remove this note.

4.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 [3] to authenticate the peers.  If a client
   authenticates a server it MUST validate the certificate.
   Authentication in the specification means that it must actually check
   the certificate other than just exchange the certificate.

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
   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.

Miao & Yuzhi            Expires October 25, 2007                [Page 5]

Internet-Draft      TLS Transport Mapping for Syslog          April 2007

   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 existing practice, it is deprecated and
   Certification Authorities are encouraged to use the dNSName instead.

   Matching is performed using the matching rules specified by RFC3280.
   Names may contain the wildcard character * which is considered to
   match any single domain name component or component fragment.  E.g.,
   * matches but not f*.com matches but not  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].

   In some cases, the iPAddress subjectAltName presents in the
   certificate, it must exactly match the IP address configured or
   resolved from 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 other
   type subjectAltName for certification verification, such as
   ipAddress.  If more than one identity of a given type presents 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, user
   oriented clients MUST either notify the user (clients MAY give the
   user the opportunity to continue with the connection in any case) or
   terminate the connection with a bad certificate error.  Automated
   clients MUST log the error to an appropriate audit log (if available)
   and SHOULD terminate the connection (with a bad certificate error).
   Automated clients MAY provide a configuration setting that disables
   this check, but MUST provide a setting which enables it.

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.
   The subjectAltName may be host name, IP address, MAC, or device ID
   etc.  SubjectAltName is not necessarily unique for different
   certificate, 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.

Miao & Yuzhi            Expires October 25, 2007                [Page 6]

Internet-Draft      TLS Transport Mapping for Syslog          April 2007

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 security
   requirement of requested session to make sure the resumed session
   provides proper security.

4.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 records.  The
   application data is defined with the following ABNF [5] expression:




   SP = %d32

   NONZERO-DIGIT = %d49-57


   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 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, the
   specification requires that a receiver MUST be able to process
   message with size up to and including 2048 octets.  Receiver SHOULD
   be able to process message with size up to and including 8192 octets.

Miao & Yuzhi            Expires October 25, 2007                [Page 7]

Internet-Draft      TLS Transport Mapping for Syslog          April 2007

4.4.  Closure

   A TLS client MUST close the associated TLS connection if the
   connection is not expected to deliver Syslog message later.  It MUST
   send a TLS close_notify alert before closing the connection.  A
   client MAY choose not to 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 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 a
   connection.  The server MUST attempt to initiate an exchange of
   close_notify alerts with the client before closing the connection.
   Servers those 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

5.  Security Considerations

5.1.  Authentication

   TLS supports three authentication modes: authentication of both
   parties, server authentication with an unauthenticated client, and
   total anonymity.  An implementation of this specification MUST
   support all three authentication modes for interoperability.

   It is RECOMMENDED that mutual authentication should be deployed in
   all cases as that will prevent masquerade attacks, modification of
   the messages, and disclosure of the contents of the messages.  Server
   authentication does not prevent masquerade attacks but does prevent
   modification and disclosure.  Unauthenticated TLS sessions does not
   address any of the threats as an unauthenticated TLS session is
   susceptible to a man in the middle attack, deploying Syslog over TLS
   with total anonymity is NOT RECOMMENDED.

   TLS authentication and the establishment of secrets 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 receiver authenticates the sender/

Miao & Yuzhi            Expires October 25, 2007                [Page 8]

Internet-Draft      TLS Transport Mapping for Syslog          April 2007

   relay to ensure that information received is authentic.

5.2.  Cipher Suites

   TLS [6] specifies a mandatory cipher suite to enable minimum
   interoperability for TLS implementation.  This specification does not
   specify a mandatory cipher suite other than the one in TLS
   specification, and the one for TLS applies to this specification for
   minimum interoperability purpose.

   If there is update to TLS specification in the future, the latest
   mandatory cipher suite in the update will apply to this
   specification, too.  The implementors 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
   implementors 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 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-19 (work in progress), November 2006.

Miao & Yuzhi            Expires October 25, 2007                [Page 9]

Internet-Draft      TLS Transport Mapping for Syslog          April 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.

   [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

   Miao Fuyou
   Huawei Technologies
   No. 3, Xinxi Rd
   Shangdi Information Industry Base
   Haidian District, Beijing  100085
   P. R. China

   Phone: +86 10 8288 2008

   Ma Yuzhi
   Huawei Technologies
   No. 3, Xinxi Rd
   Shangdi Information Industry Base
   Haidian District, Beijing  100085
   P. R. China

   Phone: +86 10 8288 2008

Miao & Yuzhi            Expires October 25, 2007               [Page 10]

Internet-Draft      TLS Transport Mapping for Syslog          April 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

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

   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


   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Miao & Yuzhi            Expires October 25, 2007               [Page 11]