Syslog Working Group                                             F. Miao
Internet-Draft                                                  M. Yuzhi
Expires: October 20, 2006                            Huawei Technologies
                                                          April 18, 2006


                    TLS Transport Mapping for SYSLOG
                 draft-ietf-syslog-transport-tls-01.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 October 20, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document describes the security threats to Syslog and counter
   measures of using Transport Layer Security(TLS) protocol for such
   threats.  Different phases are defined for using TLS to secure
   Syslog, such as initiation, sending data and closure phases.







Miao & Yuzhi            Expires October 20, 2006                [Page 1]


Internet-Draft      TLS Transport Mapping for SYSLOG          April 2006


Table of Contents

   1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Security Requirement of Syslog . . . . . . . . . . . . . . . .  3
   3.  Introduction of TLS  . . . . . . . . . . . . . . . . . . . . .  4
     3.1.  How TLS works  . . . . . . . . . . . . . . . . . . . . . .  4
     3.2.  Security Properties  . . . . . . . . . . . . . . . . . . .  4
   4.  TLS to secure Syslog . . . . . . . . . . . . . . . . . . . . .  5
   5.  Protocol Elements  . . . . . . . . . . . . . . . . . . . . . .  5
     5.1.  protocol Port  . . . . . . . . . . . . . . . . . . . . . .  5
     5.2.  Initiation . . . . . . . . . . . . . . . . . . . . . . . .  6
     5.3.  Sending data . . . . . . . . . . . . . . . . . . . . . . .  6
       5.3.1.  Frame Length . . . . . . . . . . . . . . . . . . . . .  7
     5.4.  Closure  . . . . . . . . . . . . . . . . . . . . . . . . .  7
   6.  Security Consideration . . . . . . . . . . . . . . . . . . . .  7
     6.1.  TLS and Syslog Signature . . . . . . . . . . . . . . . . .  8
     6.2.  Authentication . . . . . . . . . . . . . . . . . . . . . .  8
     6.3.  Generic Certificate  . . . . . . . . . . . . . . . . . . .  8
     6.4.  TLS Session Resumption . . . . . . . . . . . . . . . . . .  8
   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  9
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     8.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
     8.2.  Informative References . . . . . . . . . . . . . . . . . .  9
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
   Intellectual Property and Copyright Statements . . . . . . . . . . 10


























Miao & Yuzhi            Expires October 20, 2006                [Page 2]


Internet-Draft      TLS Transport Mapping for SYSLOG          April 2006


1.  Terminology

   The following definitions are used in this document:

   o  A sender is an application that can generate and send or forward a
      Syslog [2] message from an application to another application.
      Note: the definition of sender is different from syslog-protocol.

   o  A receiver is an application that can receive a Syslog message.

   o  A originator is an application that can generate a Syslog message.

   o  A relay is an application that can receive syslog messages and
      forward them to another receiver.  A relay will be both a sender
      and receiver.

   o  A collector is an application that receives messages and does not
      relay them to any other receiver.

   o  A TLS client is an application that initiate a TLS connection by
      sending a Client Hello to a peer.

   o  A TLS server is an application that receives a Client Hello from a
      peer and replies 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 Requirement of Syslog

   Syslog messages may pass several hops to arrive at the intended
   receiver.  Some intermediary networks may not be trusted by the
   sender or the receiver or both because the network is in a different
   security domain or at a different security level from the receiver or
   sender.  Another security concern is that the sender 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 may send messages to a
      legitimate receiver, or an unauthorized receiver tries to deceive
      a legitimate sender into sending Syslog messages to it.

   o  Modification.  An attacker between the sender and receiver may
      modify an in-transit Syslog message from the sender and then



Miao & Yuzhi            Expires October 20, 2006                [Page 3]


Internet-Draft      TLS Transport Mapping for SYSLOG          April 2006


      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 of Syslog message may be trivial for a potential
      attacker, but some data may be critical to launch an attack, 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 message or alter the
      delivery sequence.  Syslog protocol itself is not based on flow,
      but it is possible that an event in a Syslog message semantically
      relates to other events in other messages.

   The following threats are deemd to be of lesser importance for
   syslog, and are not addressed in this document:

   o  Denial of Service

   o  Traffic Analysis


3.  Introduction of TLS

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, as
   well as report errors.  Then, there is an ongoing layered record
   protocol that handles encryption, compression, and reassembly for the
   remainder of the connection.  An application data protocol, such as
   Syslog, is layered on the record protocol.

3.2.  Security Properties

   TLS record protocol is used to encapsulate various higher level
   protocols.  It provides connection security with confidentiality,
   integrity, authentication, and replay prevention.

   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



Miao & Yuzhi            Expires October 20, 2006                [Page 4]


Internet-Draft      TLS Transport Mapping for SYSLOG          April 2006


   handshake protocol.  The secret is kept private even if there is an
   eavesdropper in the middle.

   Integrity is provided by using HMAC [6] (computed with secure hash
   function) 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 certificate and signature, based on
   asymmetric cryptography.

   Replay prevention is provided by using a Sequence Number in each TLS
   record which is used to detect potential delete and replay of a
   record or alteration of the delivery sequence.


4.  TLS to secure Syslog

   UDP transport [7] is popular for Syslog, but it does not address
   security.  TLS can be used to counter all the major and secondary
   threats to Syslog described in section 2:

   o  Confidentiality to counter disclosure to message

   o  Integrity check to counter modification to 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 [9].  But, it is not ensured that the protocol specification
   defined in this document applicable to BSD Syslog.


5.  Protocol Elements

5.1.  protocol Port

   A Syslog sender is always a TLS client and a Syslog receiver is
   always a TLS server.  A listening port is allocated for Syslog over
   TLS.  A Syslog receiver with TLS transport listens on TCP port NNN,
   which will be IANA-assigned and is less than 1024.







Miao & Yuzhi            Expires October 20, 2006                [Page 5]


Internet-Draft      TLS Transport Mapping for SYSLOG          April 2006


5.2.  Initiation

   The sender 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 may then send the first Syslog
   message.

   TLS uses certificate [5] to authenticate the peers.  When sender
   authenticates a receiver it MUST validate the certificate.  It MAY
   check the common name(CN) of the certificate against the host name of
   the receiver if it has a priori knowledge on common name/host name
   mapping.  If the common name does not match the host name, the sender
   SHOULD send an "access_denied" error alert with TLS alert protocol to
   terminate handshake, and then close the connection.

   When a receiver authenticates a sender, receiver MUST validate the
   certificate.  A sender's certificate may be:

   o  Unique certificate, which is issued to a host and whose Common
      Name may be host name or device ID.

   o  Generic certificate, which is issued to a class of application or
      device.  For example, all cable modems from a vendor are issued
      the same certificate.

   o  Other certificate.

   A sender certificate may be issued by a operator when being
   provisioned or by a vendor when the device is manufactured.  This
   document does not define how the sender certificate is issued.

   An administrator should decide what security level (e.g.
   cryptographic algorithms and length of keys) is required.  It is
   local policy and up to administrator's decision.  Syslog applications
   should be implemented in a manner that permits administrators to
   select the cryptographic level they desire.

   An earlier TLS session or another active session MAY be resumed to
   save the effort of TLS handshake.  The security parameters of a
   resumed session are reused for the current session.  The certificate
   MUST be checked when resuming a session.  If the resumed session and
   current session use different certificates, resumption MUST not
   happen.

5.3.  Sending data

   All Syslog messages MUST be sent as TLS "application data".  There
   MAY be multiple Syslog message in same TLS record.  The application



Miao & Yuzhi            Expires October 20, 2006                [Page 6]


Internet-Draft      TLS Transport Mapping for SYSLOG          April 2006


   data is defined with following ABNF [3] expression:

   APPLICATION-DATA = 1*SYSLOG-FRAME

   SYSLOG-FRAME = FRAME-LEN SP SYSLOG-MSG

   FRAME-LEN = NONZERO-DIGIT 0*DIGIT

   SP = %d32

   DIGIT = %d48 / NONZERO-DIGIT

   NONZERO-DIGIT = %d49-57

   SYSLOG-MSG is defined in Syslog [2]protocl.

5.3.1.  Frame Length

   The frame length is the octect counter of a SYSLOG frame including
   the FRAME-LEN and SP parts.  A reciever MUST use frame length field
   to delimit a syslog message.

5.4.  Closure

   A sender MUST close a connection if it is not using the connection.
   It MUST send a TLS closure_notify alert before closing the
   connection.  A sender MAY choose not to wait for the receiver's
   closure_notify alert and simply close the connection, thus generating
   an incomplete close on the receiver side.  Once the receiver gets
   closure_notify from the sender, it MUST reply with a closure_notify
   unless it becomes aware of the connection is already closed by sender
   (e.g. indicated by TCP).

   When there are no data received from a connection for a long time (it
   is up to the application to decide what "long" means), a receiver MAY
   close a connection.  The receiver MUST attempt to initiate an
   exchange of closure_notify alerts with the sender 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 side.  When the sender
   has received the closure_notify alert from the receiver and still has
   pending data to send, sender SHOULD send the pending data before
   sending closure_notify alert.


6.  Security Consideration





Miao & Yuzhi            Expires October 20, 2006                [Page 7]


Internet-Draft      TLS Transport Mapping for SYSLOG          April 2006


6.1.  TLS and Syslog Signature

   TLS transport and Syslog Signature [8] address quite different
   security requirements.  Basically Syslog signature is between an
   originator and a collector.  Contrastively TLS transport is between
   sender and receiver.  The Peer identity authentication of TLS checks
   whether the data is received from a legitimate Syslog peer (message
   originator or relay), but Syslog signature checks whether the data
   generated by a specific originator.  It is possible that
   administrator to enable both TLS and signature to meet specific
   requirement.

6.2.  Authentication

   TLS supports three authentication modes: authentication of both
   parties, server authentication with an unauthenticated client, and
   total anonymity.

   TLS authentication and secret establishing is based on certificates
   and asymmetric cryptography, and it makes TLS transport much more
   costly than UDP transport.  An attacker may initialize and keep a lot
   of TLS connection to the receiver to launch a denial of service
   attack.  In some scenarios it may be preferable to authenticate a
   sender, i.e. authentication of both parties.  The operator SHOULD
   decide whether the preference applies.

   In some scenarios, a sender may authenticate a receiver, i.e. server
   authentication.  When confidentiality is a concern and data
   encryption is chosen, the receiver MUST be authenticated by the
   sender to make sure it is talking to the right peer.  If receiver is
   not authenticated, an attacker may eavesdrop all Syslog message,
   which will invalidate confidentiality.

6.3.  Generic Certificate

   When a certificate is issued to a class of device or application, the
   certificate may be shared by multiple hosts.  It means that multiple
   hosts own the private key of the certificate.  When certificate in
   one host is compromised, all other communication binding to the
   certificate is in risk.

6.4.  TLS Session Resumption

   Different applications in same host may have different security level
   (e.g. kernel may have higher security level than a document editor).
   The application can decrypt the Syslog messages of a resuming or
   resumed session with same cipher parameters.  When a session is being
   resumed from an application in a different security level care must



Miao & Yuzhi            Expires October 20, 2006                [Page 8]


Internet-Draft      TLS Transport Mapping for SYSLOG          April 2006


   be taken to avoid sensitive data is disclosed to unauthorized
   application.  A sensitive session must not be resumable.


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


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-16 (work in progress), January 2006.

   [3]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
        Specifications: ABNF", RFC 2234, November 1997.

   [4]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
        RFC 2246, January 1999.

   [5]  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.

   [6]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing
        for Message Authentication", RFC 2104, February 1997.

8.2.  Informative References

   [7]  Okmianski, A., "Transmission of syslog messages over UDP",
        draft-ietf-syslog-transport-udp-06 (work in progress),
        November 2005.

   [8]  Kelsey, J., "Signed syslog Messages", draft-ietf-syslog-sign-17
        (work in progress), November 2005.

   [9]  Lonvick, C., "The BSD Syslog Protocol", RFC 3164, August 2001.




Miao & Yuzhi            Expires October 20, 2006                [Page 9]


Internet-Draft      TLS Transport Mapping for SYSLOG          April 2006


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


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



Miao & Yuzhi            Expires October 20, 2006               [Page 10]


Internet-Draft      TLS Transport Mapping for SYSLOG          April 2006


   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 currently provided by the
   Internet Society.



























Miao & Yuzhi            Expires October 20, 2006               [Page 11]