SYSLOG Working Group T. Petch Internet-Draft Engineering Networks Ltd Intended status: Informational R. Gerhards Expires: February 1, 2007 Adiscon GmbH July 31, 2006 DTLS transport mapping for SYSLOG draft-petch-gerhards-syslog-transport-dtls-00.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 February 1, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document describes the transport of syslog messages over DTLS (Datagram Transport Level Security). It provides a secure transport for syslog messages in cases where a connection-less transport is desired. Petch & Gerhards Expires February 1, 2007 [Page 1] Internet-Draft DTLS transport mapping for SYSLOG July 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Security requirements for syslog . . . . . . . . . . . . . 3 1.4. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.5. DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.6. Client and server . . . . . . . . . . . . . . . . . . . . 5 2. DTLS usage . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1. Authentication . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Port number . . . . . . . . . . . . . . . . . . . . . . . 7 2.3. Invoking DTLS . . . . . . . . . . . . . . . . . . . . . . 8 2.4. DTLS connection termination . . . . . . . . . . . . . . . 8 2.5. Delineation of datagrams . . . . . . . . . . . . . . . . . 9 2.6. Choice of ciphersuite . . . . . . . . . . . . . . . . . . 9 2.7. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 9 2.8. TLS extensions . . . . . . . . . . . . . . . . . . . . . . 10 3. Security Considerations . . . . . . . . . . . . . . . . . . . 11 4. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.1. Normative . . . . . . . . . . . . . . . . . . . . . . . . 12 7.2. Informative . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Petch & Gerhards Expires February 1, 2007 [Page 2] Internet-Draft DTLS transport mapping for SYSLOG July 2006 1. Introduction The syslog protocol allows a host to send event notification messages across the Internet to another host. This memo describes the use of DTLS [4] to secure that syslog traffic, using UDP as the transport protocol. DTLS is TLS1.1 [3] modified as little as possible; understanding DTLS requires an understanding of TLS. This introduction provides an overview of TLS followed by an overview of the modifications that DTLS makes, as well as defining syslog terminology and syslog security requirements. The rest of the memo defines the use of TLS/ DTLS features to secure syslog traffic. 1.1. Conventions Used in This Document 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 RFC2119 [1]. 1.2. Terminology The following definitions are taken from syslog-protocol [5] o An application that can generate a syslog message is called a "sender". o An application that can receive a syslog message is called a "receiver". o An application that can receive syslog messages and forward them to another receiver is called a "relay". o An application that receives messages and does not relay them to any other receiver is called a "collector". A single application can have multiple roles at the same time. 1.3. Security requirements for syslog As a result of discussions on the syslog-sec mailing list, three primary threats have been identified for syslog: o Modification of information; the contents of a message are altered in transit between a syslog sender/relay and syslog collector/ relay, either maliciously or accidentally. o Masquerade; messages are sent by, or sent to, the 'wrong' party masquerading as the intended party. Masquerade of the sender of syslog messages is seen as of greater concern than masquerade of the recipient ie the latter may not be considered a threat in some environments. Petch & Gerhards Expires February 1, 2007 [Page 3] Internet-Draft DTLS transport mapping for SYSLOG July 2006 o Disclosure; the contents of messages are disclosed when they should not be, for example, revealing the security credentials of a user. The extent to which this is a threat depends on the content of the syslog message and this may not be considered a threat in some environments. Traffic Analysis and Denial of Service are not considered threats to syslog. 1.4. TLS DTLS is TLS modified as little as possible to run over an unreliable transport. TLS1.1 [3] can provide a secure transport connection between two endpoints and can provide protection against all the threats to syslog identified above. It runs as a shim, between the application layer and a reliable transport (normally TCP), and sets up a tunnel between the endpoints. Using TCP as that transport brings more than reliability - eg error detection and recovery, flow control, connections - which may not be suitable for the application; DTLS offers the option of TLS over UDP, adding reliability to UDP but without all the additional features that TCP brings. As such, it offers an attractive security option for UDP-based applications. TLS negotiates options for compression, key exchange, authentication and encryption. Compression is negotiated per se and, while likely to be a desirable feature for the character-oriented syslog, is not seen as an aspect of security and so will not be considered further here. The other three options come as a set, one of a number of predefined ciphersuites, and it is the ciphersuite, not an individual option, that is negotiated. The currently defined ciphersuites can be found on the IANA website [9]. Thus the ciphersuite known as TLS_RSA_WITH_3DES_EDE_CBC_SHA uses 3DES_EDE with CBC, for encryption, SHA when a hash is required and a PKI certificate with an RSA public key valid for encryption as the basis for end system authentication. This is the default ciphersuite, the one that an application is REQUIRED to implement, for inter-operability, unless the usage of TLS by the application is specified otherwise in an RFC. Different ciphersuites provide different levels of security with respect to each of key exchange, message authentication and encryption, ranging from none through weak to strong. Security is a Petch & Gerhards Expires February 1, 2007 [Page 4] Internet-Draft DTLS transport mapping for SYSLOG July 2006 dynamic field, with techniques being reclassified from strong to weak, eg as a result of advances in mathematics or of an increase in the computing power available to a potential attacker. At the same time, new techniques appear, and are in turn incorporated into TLS (and other) ciphersuites. The user of TLS, whether for syslog or any other application, MUST verify that the ciphersuite in use provides adequate security for their particular environment at the time that TLS is used. Any syslog application invoking TLS SHOULD verify that the ciphersuite in use meets the minimum standards of the application and MAY provide customisation to specify a minimum acceptable one. Disclosure is identified as a threat to syslog and countering this implies the use of encryption. If, in a particular environment, disclosure is not regarded as a threat, as when the network is physically secure, then the use of a ciphersuite with NULL encryption would be appropriate; this may be a consideration where the syslog client is a device with limited processing capability. 1.5. DTLS DTLS is TLS, modified, as little as possible, to run over an unreliable transport (eg UDP, DCCP). TLS decryption requires messages to arrive in sequence so DTLS adds a sequence number to the record header in order to detect reordering. The TLS handshake requires reliable delivery so DTLS specifies timeouts to detect packet loss. DTLS records are required to fit into a single datagram. This represents no change for a UDP application - eg syslog - but is an issue for the TLS handshake protocol, where, as RFC4347 [4] points out, messages are, in practice, several kilobytes (of, eg, a certificate chain). DTLS adds fragmentation to the handshake protocol and recommends PMTU discovery. Multiple application records may appear in a single DTLS datagram but must not span DTLS datagrams. Finally, DTLS adds to the transport the concept of a "connection", starting with the TLS handshake, ending with TLS closure alerts. 1.6. Client and server TLS evolved in the context of HTTP (with the protocol identifier https: [11]), an environment of powerful servers and relatively powerful workstations. As such, the cost and use of the security algorithms - eg public key encryption, certificate chains - is of limited impact. The security is asymmetric, with server Petch & Gerhards Expires February 1, 2007 [Page 5] Internet-Draft DTLS transport mapping for SYSLOG July 2006 authentication to client as mandatory (assuming that the ciphersuite specifies authentication) while client authentication is optional. This also fits well with HTTP where the client, commonly a human user of a workstation, wants to confirm that they are talking to the server that they think they are and so receive a server certificate which can then be verified. [11] specifies that if the client cannot validate the certificate it is offered, then it should pass the decision to a user, or, where there is no user, then it should terminate the connection. This model does not carry across well to syslog. A syslog device may be a powerful file or Web server, but may, on the other hand, be a low powered, unattended entry level network device, such as remotely located CPE (Customer Premises Equipment), ill-suited to verifying certificate chains and unlikely to have a human user to pass the decision on to. TLS is now used on less well-equipped devices, such as mobiles; extensions to TLS have been defined which mitigate the impact on the TLS client (eg by using URLs of certificates rather than the certificates themselves). First published separately, these extensions have now been incorporated in the base specification TLS1.2 [8]. The asymmetric approach to authentication remains, with server authentication mandatory, client authentication optional. Most applications which now run over TLS were previously running over TCP and as such already had an application level dialog. In order to invoke TLS, these applications could then change their start command (eg STARTTLS) or, having established a TCP connection, invoke TLS (eg AUTH) to make the connection secure. By contrast, syslog uses simplex UDP, a connectionless transport, with syslog messages arriving as and when, independently. DTLS adds the concept of a "connection". The decision to create a connection can be implicit, when the first message is sent; syslog client or server may need to decide when to take down the connection. syslog defines a client and server, the client being a syslog Sender or Relay, the server being a Relay or Collector. DTLS will also have a client and server as does UDP. There is a choice as to which syslog entity is the client, and which the server, both for DTLS and UDP. The use of syslog over DTLS must address the following issues: Petch & Gerhards Expires February 1, 2007 [Page 6] Internet-Draft DTLS transport mapping for SYSLOG July 2006 - authentication - connection set up - connection termination - choice of ciphersuite - choice of TLS extensions - delineation of syslog datagrams - invoking DTLS - fragmentation 2. DTLS usage 2.1. Authentication DTLS is an asymmetric protocol. Server authentication is required (when authentication is part of the ciphersuite), client authentication is optional. For syslog, the greater threat is perceived as an unauthenticated syslog client generating spurious messages, as opposed to an unauthenticated syslog server receiving them ie it is the authentication of the syslog client that is the more important. Hence it is RECOMMENDED that the syslog server should be the DTLS client. If Masquerade of the syslog server is considered a threat in a particular environment, then the syslog client SHOULD request authentication of the syslog server/DTLS client. A consequence of this mapping, of DTLS client to syslog server, is that where certificates are used for server authentication, then the syslog server is the one that has to verify the syslog client's certificates (something that it is likely to have the greater resources to do). The syslog client must have a certificate; the syslog server certificate remains optional. 2.2. Port number syslog over UDP has been allocated port 514 while syslog-conn, which uses BEEP [13], has been allocated port 601 over TCP RFC3195 [12]. IANA has also allocated port 601 over UDP on the basis of [12] although that RFC makes no mention of such a usage. This memo defines the use of port 601 for syslog over DTLS in preference to asking IANA to assign a new port. Ports are a scarce resource, especially those with values of 1024 or less, and their use should be conserved. Using different ports for slightly different applications may ease the task of the receiving host of demultiplexing the data but makes it more complex for the providers of infrastructure, eg in specifying filters in firewalls and application level gateways. The authors of this memo believe that Petch & Gerhards Expires February 1, 2007 [Page 7] Internet-Draft DTLS transport mapping for SYSLOG July 2006 the latter view should prevail, ie that there should be a port defined for secure syslog, with negotiation specifying what security there should be, DTLS or some other, yet to be specified. For UDP, no use of port 601 is defined and so its (re-)use for syslog over DTLS is seen as feasible. 2.3. Invoking DTLS The DTLS "connection" SHOULD be initiated by syslog client by sending the plain text application level command AUTH TLS SERVER when it wishes to be the DTLS server or AUTH TLS CLIENT when it wishes to be the DTLS client. The former is expected to be the usual case. (The use of DTLS, as opposed to TLS, is implicit in the use of UDP transport). The syslog server MUST respond OK if it accepts its proposed role or ERROR if does not. This is followed by TLS negotiation with syslog server/DTLS client sending DTLS Client Hello and, if the negotiation is successful, by syslog messages. 2.4. DTLS connection termination DTLS includes a mechanism for graceful shutdown - TLS1.2 [8] s.7.2.1. Closure alerts - and these SHOULD be used to terminate a DTLS connection. As specified there, either DTLS client or DTLS server may initiate a closure when it SHOULD send a close_notify alert. Any data received after a closure alert is ignored. The other party MUST send a close_notify alert of its own and close down the connection immediately, discarding any pending writes. The initiator of the close need not wait for the responding close_notify alert before closing the read side of the connection. Closure should be initiated when the syslog application determines Petch & Gerhards Expires February 1, 2007 [Page 8] Internet-Draft DTLS transport mapping for SYSLOG July 2006 that no more messages will be sent or received, or that none have been for a period of time. A suggested value for the period of time is one hour. The choice of a value should balance the resources needed to re-create the connection using DTLS against the resources used by an idle connection and the increased risk of a breach of security by keeping a DTLS connection in place longer than necessary. Although closure alerts form part of DTLS, they, like all alerts, are not retransmitted by DTLS and so may be lost over an unreliable network. 2.5. Delineation of datagrams When syslog runs upon UDP, the UDP datagram frames the syslog message. Over DTLS, syslog messages MUST be sent as DTLS application data. DTLS may place multiple DTLS records in a single datagram, each encoded consecutively. The boundaries are then determined by DTLS record framing. 2.6. Choice of ciphersuite The Ciphersuite TLS_RSA_WITH_3DES_EDE_CBC_SHA is REQUIRED. Where Disclosure is not a threat to syslog and so encryption is not necessary, and may be undesirable because of the limited processing capability of the syslog client, then TLS_RSA_WITH_NULL_SHA is RECOMMENDED. Where Pre-Shared Keys are a sufficiently strong security credential, in contrast to the more powerful X.509 Certificates, then TLS_PSK_WITH_3DES_EDE_CBC_SHA is RECOMMENDED. DTLS is defined to use the same ciphersuites as were then current for TLS but excluding those using the stream cipher RC4. New ciphersuites must specify whether or not they are suitable for DTLS and so suitable for use here. 2.7. Fragmentation syslog messages have no upper limit per se and in some environments may be up to 2**16. TLS v1.1 limits messages to 2**14; TLS Petch & Gerhards Expires February 1, 2007 [Page 9] Internet-Draft DTLS transport mapping for SYSLOG July 2006 extensions allow this to be reduced to 2**9 although, as TLS1.2 [8] points out, this may be less than needs to be sent at once and so cause the "connection" to be terminated. syslog applications SHOULD ensure that syslog messages fit within the limits of DTLS. 2.8. TLS extensions TLS Extensions, first published as RFC3546 [2] and now incorporated into TLS1.2 [8], provides a generic extension mechanism together with specific extensions suitable for a constrained environment. The general extension mechanism ensures backward compatability for devices that either do not support extensions in general or do not support a particular extension. TLS Extensions identifies wireless as a constrained environment but the constraints, such as limited processing capability or limited storage, apply elsewhere, such as with network devices supporting syslog; TLS Extensions also assumes that it is the TLS client that is constrained, not the TLS server, whereas with network devices, it is the syslog client, TLS server, that is more likely to be constrained. Hence the extensions are of limited relevance. Extensions are not mentioned in RF4347 [4] but, on the basis that DTLS is TLS modified as little as possible, are assumed to be part of DTLS. The defined extensions, beside the maximum fragment length which has already been discussed, are server name indication truncated HMAC client certificate url trusted CA certificate status request certificate hash types. Since syslog over DTLS runs over a port specific to syslog, the server name indication, which helps the DTLS server in identifying the appropriate application, is not required. Truncated HMAC reduces the HMAC to 80 bit, saving bandwidth, and is not seen as relevant to syslog. Client certificate URL allows the client, but not the server, to use a URL instead of a certificate per se. Likewise trusted CA allows the client to indicate which CAs it may use so that the server can select a suitable certificate to send. Certificate status request proposes the use of OCSP instead of CRL, saving bandwith; certificate hash types allows the client to specify which hash algorithms it Petch & Gerhards Expires February 1, 2007 [Page 10] Internet-Draft DTLS transport mapping for SYSLOG July 2006 supports. Each of these four cases is designed to help the DTLS client, the syslog server, and so are of limited value since it is expected that it will be the DTLS server, syslog client, that is constrained. 3. Security Considerations The whole of this memo is about security. As pointed out above, DTLS can provide security against the threats to syslog identified above but whether or not that is achieved depends on the ciphersuite in use. Users MUST ensure that the ciphersuite in use meets their needs for security, in terms of the strength of the algorithms used, whether or not encryption is used and the nature of credentials used to authenticate the parties involved. 4. Authors The authors of this draft are: Tom Petch Email: ietf2@dial.pipex.com Phone: +44-192-575-3018 Engineering Networks Ltd 18 Parkwood Close Lymm Cheshire WA13 0NQ UK Rainer Gerhards Email: rgerhards@adiscon.com Phone: +49-9349-92880 Fax: +49-9349-928820 Adiscon GmbH Mozartstrasse 21 97950 Grossrinderfeld Germany Petch & Gerhards Expires February 1, 2007 [Page 11] Internet-Draft DTLS transport mapping for SYSLOG July 2006 5. IANA Considerations There are no IANA considerations. 6. Acknowledgments This document was written using the xml2rfc tool described in [10]. 7. References 7.1. Normative [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 3546, June 2003. [3] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006. [4] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006. [5] Gerhards, R., "The syslog Protocol", draft-ietf-syslog-protocol-17 (work in progress), June 2006. [6] Wasserman, M. and T. Goddard, "Using the NETCONF Configuration Protocol over Secure Shell (SSH)", draft-ietf-netconf-ssh-06 (work in progress), March 2006. [7] Cooper, D., "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", draft-ietf-pkix-rfc3280bis-04 (work in progress), June 2006. [8] Dierks, T. and E. Rescorla, "The TLS Protocol", draft-ietf-tls-rfc4346-bis-01 (work in progress), June 2006. [9] "IANA Assigned TLS Options, http://www.iana.org/assignments/tls-parameters". 7.2. Informative [10] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. Petch & Gerhards Expires February 1, 2007 [Page 12] Internet-Draft DTLS transport mapping for SYSLOG July 2006 [11] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [12] New, D. and M. Rose, "Reliable Delivery for syslog", RFC 3195, November 2001. [13] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001. [14] 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. [15] "ITU-T Recommendation X.509 (1997 E): Information Technology - Open Systems Interconnection - "The Directory - Authentication Framework". 1988.". Authors' Addresses Tom Petch Engineering Networks Ltd 18 Parkwood Close Lymm, Cheshire WA13 0NQ UK Email: ietf2@dial.pipex.com Rainer Gerhards Adiscon GmbH Mozartstrasse 21 Grossrinderfeld, BW 97950 Germany Email: rgerhards@adiscon.com Petch & Gerhards Expires February 1, 2007 [Page 13] Internet-Draft DTLS transport mapping for SYSLOG July 2006 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 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). Petch & Gerhards Expires February 1, 2007 [Page 14]