Syslog Working Group                                        F. Miao, Ed.
Internet-Draft                                                Y. Ma, Ed.
Intended status: Standards Track                     Huawei Technologies
Expires: November 8, 2008                                J. Salowey, Ed.
                                                     Cisco Systems, Inc.
                                                             May 7, 2008


                    TLS Transport Mapping for Syslog
                 draft-ietf-syslog-transport-tls-12.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 November 8, 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 November 8, 2008                [Page 1]


Internet-Draft      TLS Transport Mapping for Syslog            May 2008


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 Authentication and Basic Authorization  . . . .  5
       4.2.2.  Client Authentication and Authorization  . . . . . . .  7
       4.2.3.  Certificate Fingerprints . . . . . . . . . . . . . . .  7
       4.2.4.  Cryptographic Level  . . . . . . . . . . . . . . . . .  8
     4.3.  Sending data . . . . . . . . . . . . . . . . . . . . . . .  8
       4.3.1.  Message Length . . . . . . . . . . . . . . . . . . . .  8
     4.4.  Closure  . . . . . . . . . . . . . . . . . . . . . . . . .  9
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
     5.1.  Authentication and Certificates  . . . . . . . . . . . . .  9
     5.2.  Cipher Suites  . . . . . . . . . . . . . . . . . . . . . . 10
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
     6.1.  Port Number  . . . . . . . . . . . . . . . . . . . . . . . 11
   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 11
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 11
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
   Intellectual Property and Copyright Statements . . . . . . . . . . 13
























Miao, et al.            Expires November 8, 2008                [Page 2]


Internet-Draft      TLS Transport Mapping for Syslog            May 2008


1.  Introduction

   This document describes the use of Transport Layer Security (TLS [5])
   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 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 November 8, 2008                [Page 3]


Internet-Draft      TLS Transport Mapping for Syslog            May 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.  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, et al.            Expires November 8, 2008                [Page 4]


Internet-Draft      TLS Transport Mapping for Syslog            May 2008


   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 typically uses certificates [3] to authenticate peers.
   Authentication and authorization of the TLS server (transport
   receiver) is described in Section 4.2.1; authentication and
   authorization of the TLS client (transport sender) is described in
   Section 4.2.2.

4.2.1.  Server Authentication and Basic Authorization

   [Editor's Note: Text referencing RFC2818 was removed, it is not clear
   that it is all the relevant to SYSLOG.]

   [Editor's Note: Option for certificate fingerprint added]

   The transport sender (TLS client) has three different options for
   authenticating and authorizing the transport receiver (TLS server).

   o  Certification path validation and subject name verification: the
      client is configured with one or more trust anchors, and for each
      transport receiver, the name to be matched against the certificate
      for authorization.  This option MUST be supported.

   o  Certificate fingerprints: For each transport receiver, the client
      is configured with a fingerprint of the server's certificate
      (which can be self-signed).  This option MUST be supported.




Miao, et al.            Expires November 8, 2008                [Page 5]


Internet-Draft      TLS Transport Mapping for Syslog            May 2008


   o  No server authentication/authorization: The client is configured
      to accept any certificate from the server.  This option MAY be
      supported, but MUST NOT be enabled by default.

   For certification path validation, client implementations MUST
   provide a mechanism for configuring one or more trust anchors, and
   MUST perform certification path validation as specified in [3].

   For subject name verification, client implementations MUST support
   configuring, for each transport receiver, the name to be matched
   against the certificate.  This name may be the host name or IP
   address used when opening the TCP connection.  Implementations MUST
   support checking the hostname against a SubjectAltName field with a
   type of dNSName and SHOULD support checking hostname against the
   Common Name portion of the Subject Distinguished Name.  Matching for
   certificate credentials is performed using the matching rules
   specified by [3].  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.
   Implementations MAY support other authorization processes matching
   against other fields in a certificate.  Implementations also MAY
   support wildcards to match a range of values.  For example, names to
   be matched against a certificate 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.

   [Editor's Note: How useful is it to match against IP address?  Do we
   expect deployments to issue certificates with IP addresses in them?
   Are IP addresses typically used in configuration? ]

   To support certificate fingerprints, client implementations MUST
   support configuring, for each transport receiver, a fingerprint of
   the server certificate.  See Section 4.2.3 for details.

   If the certificate fails authorization or validity checks, clients
   SHOULD log the error in some form or another (see next paragraph),
   and SHOULD terminate the connection with a bad certificate error.

   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, et al.            Expires November 8, 2008                [Page 6]


Internet-Draft      TLS Transport Mapping for Syslog            May 2008


4.2.2.  Client Authentication and Authorization

   The transport receiver (TLS server) has three different options for
   authenticating and authorizing the transport sender (TLS client).

   [Editor's note: At least one one authorization mechanism should be
   mandatory to implement to protect against the threat of masquerade
   listed above.]

   o  Certification path validation and subject name verification: the
      server is configured with one or more trust anchors, and a set of
      names (or wildcard patterns) to be matched against the
      certificates.  This option MUST be supported.

   o  Certificate fingerprints: The server is configured with the
      fingerprints of client certificates.  This option MUST be
      supported.

   o  No client authentication or authorization (or authorization based
      only on connection source IP address): This option MAY be
      supported, but MUST NOT be enabled by default.

   Certification path validation and subject name verification work as
   described in Section Section 4.2.2 above.  A server may allow wild
   card names to match against the certificate which will result in a
   large number of clients with valid certificates to be authorized.
   Servers SHOULD provide a mechanism to log the identity and issuer of
   an accepted certificate to enable messages received from the client
   to be associated with an authenticated entity.

   To support certificate fingerprints, server implementations MUST
   support configuring with a list of fingerprints of authorized
   certificates.  See Section Section 4.2.3 for details.

   [Editor's note: Removed section on using the same name for more that
   one host as it seems implementation specific.  Removed section on
   discussion on who issues the certificate since it is out of scope.]

4.2.3.  Certificate Fingerprints

   Both client and server implementations MUST make the certificate
   fingerprint available through a management interface.  If no other
   certificate is configured, both client and server implementations
   MUST support generating a key pair and self-signed certificate.

   The RECOMMENDED mechanism to generate a fingerprint is to take the
   SHA-1 hash of the certificate and convert the 20 byte result into 20
   colon separated, hexadecimal bytes, each represented by 2 uppercase



Miao, et al.            Expires November 8, 2008                [Page 7]


Internet-Draft      TLS Transport Mapping for Syslog            May 2008


   ASCII characters.  When a fingerprint value is displayed or
   configured the algorithm used to generate the fingerprint SHOULD be
   indicated.

4.2.4.  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 [4]
   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 [2] 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



Miao, et al.            Expires November 8, 2008                [Page 8]


Internet-Draft      TLS Transport Mapping for Syslog            May 2008


   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
   messages.  Mutual authentication means the TLS client and server are
   provisioned with necessary trust anchors and must perform certificate
   validation.

   [Editor's Note: added text on self-signed certificate validation and
   removed text on caching.]

   The use of self-signed certificates with certificate fingerprint
   authorization lists provides more protection from masquerade and man-
   in-the-middle attacks than forgoing certificate validation and
   authorization.

   [Editor's Note: It may be useful to suggest some operational practice
   that facilitates the deployment of self-signed certificates.  For



Miao, et al.            Expires November 8, 2008                [Page 9]


Internet-Draft      TLS Transport Mapping for Syslog            May 2008


   example, in order to initially populate an authorization list a
   client or server can display a certificate finger-print through a
   user interface to an administrator to be authorized and added to the
   authorization list.]

   If the client or server choose to forgo certificate validation then
   the threats listed in Section 2 may not be appropriately mitigated.
   Malicious entities may masquerade as the client or server, or they
   may insert themselves as a man-in-the middle of the conversation.
   This may result in modification and disclosure of data.  While this
   may be acceptable in a security insensitive environment, it is
   recommended that server and client are configured with certificates
   and validate received certificate against provisioned trust anchors
   and authorization lists.

   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 cipher suites for TLS that are
   regarded as too weak for the environment in which this specification
   is being used, especially older cipher suites.  This MAY lead to a
   reduction of interoperability.  It is likely that, in time, the
   cipher suite specified here will become subject to attack and the use
   of it will too be deprecated.  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.

   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 [6].  The implementers and deployers
   should also be aware of the latest TLS and other IETF cryptography
   standards including BCP86.






Miao, et al.            Expires November 8, 2008               [Page 10]


Internet-Draft      TLS Transport Mapping for Syslog            May 2008


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 and Pasi Eronen for his contributions to
   certificate authentication and authorization sections.


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]  Cooper, D., "Internet X.509 Public Key Infrastructure
        Certificate and Certificate  Revocation List (CRL) Profile",
        draft-ietf-pkix-rfc3280bis-11 (work in progress), February 2008.

   [4]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
        Specifications: ABNF", STD 68, RFC 5234, January 2008.

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

8.2.  Informative References

   [6]  Orman, H. and P. Hoffman, "Determining Strengths For Public Keys
        Used For Exchanging Symmetric Keys", BCP 86, RFC 3766,
        April 2004.



Miao, et al.            Expires November 8, 2008               [Page 11]


Internet-Draft      TLS Transport Mapping for Syslog            May 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 November 8, 2008               [Page 12]


Internet-Draft      TLS Transport Mapping for Syslog            May 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 November 8, 2008               [Page 13]