Syslog Working Group F. Miao Internet-Draft M. Yuzhi Expires: December 9, 2006 Huawei Technologies June 7, 2006 TLS Transport Mapping for SYSLOG draft-ietf-syslog-transport-tls-02.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 December 9, 2006. 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 December 9, 2006 [Page 1] Internet-Draft TLS Transport Mapping for SYSLOG June 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Security Requirements for Syslog . . . . . . . . . . . . . . . 3 3. TLS Fundamentals . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. How TLS works . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Security Properties . . . . . . . . . . . . . . . . . . . 5 4. TLS to secure Syslog . . . . . . . . . . . . . . . . . . . . . 5 5. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 5 5.1. Port Assignment . . . . . . . . . . . . . . . . . . . . . 6 5.2. Initiation . . . . . . . . . . . . . . . . . . . . . . . . 6 5.3. Sending data . . . . . . . . . . . . . . . . . . . . . . . 7 5.3.1. Frame Length . . . . . . . . . . . . . . . . . . . . . 7 5.4. Closure . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Security Consideration . . . . . . . . . . . . . . . . . . . . 8 6.1. Authentication . . . . . . . . . . . . . . . . . . . . . . 8 6.2. Generic Certificate . . . . . . . . . . . . . . . . . . . 8 6.3. TLS Session Resumption . . . . . . . . . . . . . . . . . . 8 7. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 10 Miao & Yuzhi Expires December 9, 2006 [Page 2] Internet-Draft TLS Transport Mapping for SYSLOG June 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 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 An 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 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 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 Miao & Yuzhi Expires December 9, 2006 [Page 3] Internet-Draft TLS Transport Mapping for SYSLOG June 2006 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 forward the message to receiver. Such modification may make the receiver misunderstands the message or causes 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 Fundamentals 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, compression, and reassembly for the remainder of the connection. An application data protocol, such as Syslog, is layered on the record protocol. Miao & Yuzhi Expires December 9, 2006 [Page 4] Internet-Draft TLS Transport Mapping for SYSLOG June 2006 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. 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. The secret is kept private even if there is an eavesdropper in the middle. Integrity is provided by using HMAC [6] (computed with a 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 a certificate and signature, based on 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 applicable to BSD Syslog. 5. Protocol Elements Miao & Yuzhi Expires December 9, 2006 [Page 5] Internet-Draft TLS Transport Mapping for SYSLOG June 2006 5.1. Port Assignment A Syslog sender 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. 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 a sender 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 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, the receiver MUST validate the certificate. A sender'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 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 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 Miao & Yuzhi Expires December 9, 2006 [Page 6] Internet-Draft TLS Transport Mapping for SYSLOG June 2006 another active session when a new session is requested, in order to save the expense of another TLS handshake. The security parameters of the resumed session are reused for the requested session. The certificate MUST be checked when resuming a session. If the resumed session and current session use different certificates, resumption MUST not happen. The security parameters SHOULD be checked against security requirement of requested session to make sure the resumed session provides proper security. 5.3. Sending data All Syslog messages MUST be sent as TLS "application data". There MAY be multiple Syslog message in the same TLS record. The application data is defined with the 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] protocol. 5.3.1. Frame Length The frame length is the octet count of a SYSLOG frame including the FRAME-LEN and SP parts. A receiver MUST use the frame length field to delimit a Syslog message. 5.4. Closure A Syslog sender 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 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 that the connection has already been closed by the sender (e.g., the closure was indicated by TCP). When no data is received from a connection for a long time (where the Miao & Yuzhi Expires December 9, 2006 [Page 7] Internet-Draft TLS Transport Mapping for SYSLOG June 2006 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 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, the sender 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 UDP 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 to ensure that information received is authentic. When confidentiality is a concern, a sender 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. Any communication that is bound to the certificate is at risk. 6.3. TLS Session Resumption Different applications in the same host may have different security levels (e.g., the kernel may have higher a security level than a document editor application). If a requested session resumes an existing session, then the requesting application can decrypt the Syslog messages of the resumed session using same cipher parameters as defined for the resumed session. When a session is being resumed from an application with a different security level, care must be Miao & Yuzhi Expires December 9, 2006 [Page 8] Internet-Draft TLS Transport Mapping for SYSLOG June 2006 taken to avoid disclosing sensitive data to an unauthorized application. A sensitive session must not be resumable. 7. IANA Consideration 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. 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-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. 9.2. Informative References [7] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, August 2001. Miao & Yuzhi Expires December 9, 2006 [Page 9] Internet-Draft TLS Transport Mapping for SYSLOG June 2006 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 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 December 9, 2006 [Page 10] Internet-Draft TLS Transport Mapping for SYSLOG June 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 December 9, 2006 [Page 11]