Syslog Working Group F. Miao Internet-Draft M. Yuzhi Intended status: Standards Track Huawei Technologies Expires: November 13, 2007 May 12, 2007 TLS Transport Mapping for Syslog draft-ietf-syslog-transport-tls-10.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 13, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). 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 November 13, 2007 [Page 1]
Internet-Draft TLS Transport Mapping for Syslog May 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 12 Miao & Yuzhi Expires November 13, 2007 [Page 2]
Internet-Draft TLS Transport Mapping for Syslog May 2007 1. Introduction This document describes the use of Transport Layer Security (TLS [6]) 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 A "sender" passes syslog messages to a specific transport protocol. o A "receiver" takes syslog messages from a specific transport protocol. o A "relay" forwards messages, accepting messages from originators or other relays, and sending them to collectors or other relays. o A "collector" gathers syslog content for further analysis. 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 November 13, 2007 [Page 3]
Internet-Draft TLS Transport Mapping for Syslog May 2007 o Modification. An attacker between the sender/relay and the receiver may modify an in-transit syslog message from the sender/ relay and then forward the message to the 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 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 is not addressed in this document. Miao & Yuzhi Expires November 13, 2007 [Page 4]
Internet-Draft TLS Transport Mapping for Syslog May 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 certificates [3] to authenticate peers. If a client authenticates a server it MUST validate the certificate. Authentication in this specification means that the recipient of a certificate must actually check the certificate rather than just accept a 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 November 13, 2007 [Page 5]
Internet-Draft TLS Transport Mapping for Syslog May 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 current practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead. Matching is performed using the matching rules specified by RFC3280 [3]. Names 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. 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]. If the iPAddress subjectAltName is present in the certificate, it must exactly match the IP address configured or resolved from the 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 any other type subjectAltName for certificate verification, such as ipAddress. 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. If the hostname does not match the identity in the certificate, clients SHOULD log the error in some form or another (see next paragraph), and SHOULD terminate the connection with a bad certificate error. Clients MAY provide a configuration setting that disables this check but MUST enable it by default. 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. 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 the host name, IP address, MAC, device ID, etc. SubjectAltName is not necessarily unique for different certificates. For example, certificates for some types of printer Miao & Yuzhi Expires November 13, 2007 [Page 6]
Internet-Draft TLS Transport Mapping for Syslog May 2007 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. 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 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 [5] 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 receiver MUST use the message length to delimit a syslog message. There is no upper limit for a message length per se. Miao & Yuzhi Expires November 13, 2007 [Page 7]
Internet-Draft TLS Transport Mapping for Syslog May 2007 However, in order to establish a baseline for interoperability, this specification requires that a receiver MUST be able to process messages with a length up to and including 2048 octets. 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 TLS supports three authentication modes: authentication of both parties, server authentication with an unauthenticated client, and total anonymity. An implementation compliant with this specification MUST support all three authentication modes for interoperability. It is RECOMMENDED that mutual authentication 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 do 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. Miao & Yuzhi Expires November 13, 2007 [Page 8]
Internet-Draft TLS Transport Mapping for Syslog May 2007 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 receiver authenticate the sender/ 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 any mandatory cipher suite other than the one in the TLS specification, and the cipher suite for TLS applies to this specification for minimum interoperability purposes. If there is an update to the TLS specification in the future, the latest mandatory cipher suite in the update will apply to this specification, too. 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 [4]. The implementers 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 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. 8. References Miao & Yuzhi Expires November 13, 2007 [Page 9]
Internet-Draft TLS Transport Mapping for Syslog May 2007 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. [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 Email: miaofy@huawei.com URI: www.huawei.com Miao & Yuzhi Expires November 13, 2007 [Page 10]
Internet-Draft TLS Transport Mapping for Syslog May 2007 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 November 13, 2007 [Page 11]
Internet-Draft TLS Transport Mapping for Syslog May 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 "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 & Yuzhi Expires November 13, 2007 [Page 12]