Datagram Transport Layer Security (DTLS) Transport Mapping for Syslog
draft-ietf-syslog-dtls-06.txt

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.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

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

This Internet-Draft will expire on January 9, 2011.

Copyright Notice

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

Table of Contents

1.  Introduction

2.  Terminology

3.  Security Requirements for Syslog

4.  Using DTLS to Secure Syslog

5.  Protocol Elements
    5.1.  Transport
    5.2.  Port and Service Code Assignment
    5.3.  Initiation
        5.3.1.  Certificate-Based Authentication
    5.4.  Sending data
        5.4.1.  Message Size
    5.5.  Closure

6.  Congestion Control

7.  Security Policies

8.  IANA Consideration

9.  Security Considerations
    9.1.  DTLS Renegotiation
    9.2.  Message Loss
    9.3.  Private Key Generation
    9.4.  Trust Anchor Installation and Storage

10.  Acknowledgements

11.  References
    11.1.  Normative References
    11.2.  Informative References

§  Authors' Addresses

1.  Introduction

The syslog protocol [RFC5424] (Gerhards, R., “The Syslog Protocol,” March 2009.) is designed to run over different transports for different environments. This document defines the transport of syslog messages over the datagram transport layer security protocol (DTLS) [RFC4347] (Rescorla, E. and N. Modadugu, “Datagram Transport Layer Security,” April 2006.).

The datagram transport layer security protocol (DTLS) [RFC4347] (Rescorla, E. and N. Modadugu, “Datagram Transport Layer Security,” April 2006.) is designed to meet the requirements of applications that need secure datagram transport. DTLS has been mapped onto different transports, including UDP [RFC0768] (Postel, J., “User Datagram Protocol,” August 1980.) and DCCP [RFC4340] (Kohler, E., Handley, M., and S. Floyd, “Datagram Congestion Control Protocol (DCCP),” March 2006.). This memo defines both options, namely syslog over DTLS over UDP and syslog over DTLS over DCCP.

2.  Terminology

The following definitions from [RFC5424] (Gerhards, R., “The Syslog Protocol,” March 2009.) are used in this document:

• An "originator" generates syslog content to be carried in a message.
• A "collector" gathers syslog content for further analysis.
• A "relay" forwards messages, accepting messages from originators or other relays, and sending them to collectors or other relays.
• A "transport sender" passes syslog messages to a specific transport protocol.
• A "transport receiver" takes syslog messages from a specific transport protocol.

This document adds the following definitions:

• A "DTLS client" is an application that can initiate a DTLS Client Hello to a server.
• A "DTLS server" is an application that can receive a DTLS Client Hello from a client 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 [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

3.  Security Requirements for Syslog

The security requirements for the transport of syslog messages are discussed in Section 2 of [RFC5425] (Miao, F., Ma, Y., and J. Salowey, “Transport Layer Security (TLS) Transport Mapping for Syslog,” March 2009.). These also apply to this specification.

The following secondary threat is also considered in this document:

• Denial of service is discussed in [RFC5424] (Gerhards, R., “The Syslog Protocol,” March 2009.), which states that an attacker may send more messages to a transport receiver than the transport receiver could handle. When using a secure transport protocol handshake, an attacker may use a spoofed IP source to engage the server in a cryptographic handshake to deliberately consume the server's resources.

4.  Using DTLS to Secure Syslog

DTLS can be used as a secure transport to counter all the primary threats to syslog described in [RFC5425] (Miao, F., Ma, Y., and J. Salowey, “Transport Layer Security (TLS) Transport Mapping for Syslog,” March 2009.):

• Confidentiality to counter disclosure of the message contents.
• Integrity checking to counter modifications to a message on a hop- by-hop basis.
• Server or mutual authentication to counter masquerade.

In addition DTLS also provides:

• A cookie exchange mechanism during handshake to counter Denial of Service attacks.
• A sequence number in the header to counter replay attacks.

Note: This secure transport (i.e., DTLS) only secures syslog transport in a hop-by-hop manner, and is not concerned with the contents of syslog messages. In particular, the authenticated identity of the transport sender (e.g., subject name in the certificate) is not necessarily related to the HOSTNAME field of the syslog message. When authentication of syslog message origin is required, [RFC5848] (Kelsey, J., Callas, J., and A. Clemm, “Signed Syslog Messages,” May 2010.) can be used.

5.  Protocol Elements

5.1.  Transport

DTLS can run over multiple transports. Implementations of this specification MUST support DTLS over UDP and SHOULD support DTLS over DCCP [RFC5238] (Phelan, T., “Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP),” May 2008.). Transports, such as UDP or DCCP do not provide session multiplexing and session-demultiplexing. In such cases, the application implementer provides this functionality by mapping a unique combination of the remote address, remote port number, local address and local port number to a session.

Each syslog message is delivered by the DTLS record protocol, which assigns a sequence number to each DTLS record. Although the DTLS implementer may adopt a queue mechanism to resolve reordering, it may not assure that all the messages are delivered in order when mapping on the UDP transport.

When DTLS runs over an unreliable transport, such as UDP, reliability is not provided. With DTLS, an originator or relay may not realize that a collector has gone down or lost its DTLS connection state so messages may be lost.

Syslog over DTLS over TCP MUST NOT be used. If a secure transport is required with TCP then the appropriate security mechanism is syslog over TLS as described in [RFC5425] (Miao, F., Ma, Y., and J. Salowey, “Transport Layer Security (TLS) Transport Mapping for Syslog,” March 2009.).

5.2.  Port and Service Code Assignment

A syslog transport sender is always a DTLS client and a transport receiver is always a DTLS server.

The UDP and DCCP port [TBD] has been allocated as the default port for syslog over DTLS as defined in this document. The service code [TBD] has been assigned to syslog.

5.3.  Initiation

The transport sender initiates a DTLS connection by sending a DTLS Client Hello to the transport receiver. Implementations MUST support the denial of service countermeasures defined by DTLS. When these countermeasures are used, the transport receiver responds with a DTLS Hello Verify Request containing a cookie. The transport sender responds with a DTLS Client Hello containing the received cookie which initiates the DTLS handshake. The transport sender MUST NOT send any syslog messages before the DTLS handshake has successfully completed.

Implementations MUST support DTLS 1.1 (Rescorla, E. and N. Modadugu, “Datagram Transport Layer Security,” April 2006.) [RFC4347] and MUST support the mandatory to implement cipher suite, which is TLS_RSA_WITH_AES_128_CBC_SHA as specified in [RFC5246] (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.). If additional cipher suites are supported, then implementations MUST NOT negotiate a cipher suite that employs NULL integrity or authentication algorithms.

Where privacy is REQUIRED, then implementations must either negotiate a cipher suite that employs a non-NULL encryption algorithm or else achieve privacy by other means, such as a physically secured network.

However, as [RFC5424] (Gerhards, R., “The Syslog Protocol,” March 2009.) section 8 points out, 'In most cases, passing clear-text messages is a benefit to the operations staff if they are sniffing the packets from the wire.' and so where privacy is not a requirement, then it is advantageous to use a NULL encryption algorithm.

5.3.1.  Certificate-Based Authentication

The mandatory to implement ciphersuites for DTLS use certificates [RFC5280] (Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,” May 2008.) to authenticate peers. Both syslog transport sender (DTLS client) and syslog transport receiver (DTLS server) MUST implement certificate-based authentication. This consists of validating the certificate and verifying that the peer has the corresponding private key. The latter part is performed by DTLS. To ensure interoperability between clients and servers, the methods for certificate validation defined in sections 4.2.1 and 4.2.2 of [RFC5425] (Miao, F., Ma, Y., and J. Salowey, “Transport Layer Security (TLS) Transport Mapping for Syslog,” March 2009.) SHALL be implemented.

Both transport receiver and transport sender implementations MUST provide means to generate a key pair and self-signed certificate in case a key pair and certificate are not available through another mechanism.

The transport receiver and transport sender SHOULD provide mechanisms to record the certificate or certificate fingerprint used by the remote endpoint for the purpose of correlating an identity with the sent or received data.

5.4.  Sending data

All syslog messages MUST be sent as DTLS "application data". It is possible that multiple syslog messages be contained in one DTLS record, or that a syslog message be transferred in multiple DTLS records. The application data is defined with the following ABNF (Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” January 2008.) [RFC5234] 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 (Gerhards, R., “The Syslog Protocol,” March 2009.) [RFC5424] protocol.

5.4.1.  Message Size

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. As stated in [RFC4347] (Rescorla, E. and N. Modadugu, “Datagram Transport Layer Security,” April 2006.), a DTLS record MUST NOT span multiple datagrams. When mapping onto different transports, DTLS has different record size limitations. For UDP, see section 3.2 of [RFC5426] (Okmianski, A., “Transmission of Syslog Messages over UDP,” March 2009.). For DCCP, the application implementer SHOULD determine the maximum record size allowed by DTLS protocol running over DCCP, as specified in [RFC4340] (Kohler, E., Handley, M., and S. Floyd, “Datagram Congestion Control Protocol (DCCP),” March 2006.). The message size SHOULD NOT exceed the DTLS maximum record size limitation of 2^14 bytes. To be consistent with [RFC5425] (Miao, F., Ma, Y., and J. Salowey, “Transport Layer Security (TLS) Transport Mapping for Syslog,” March 2009.), in establishing a baseline for interoperability, this specification requires that a transport receiver MUST be able to process messages with a length up to and including 2048 octets. Transport receivers SHOULD be able to process messages with lengths up to and including 8192 octets.

See section A.2 of [RFC5424] (Gerhards, R., “The Syslog Protocol,” March 2009.) for implementation guidance on message length, including fragmentation.

5.5.  Closure

A transport sender MUST close the associated DTLS connection if the connection is not expected to deliver any syslog messages later. It MUST send a DTLS close_notify alert before closing the connection. A transport sender (DTLS client) MAY choose to not wait for the transport receiver's close_notify alert and simply close the DTLS connection. Once the transport receiver gets a close_notify from the transport sender, it MUST reply with a close_notify.

When no data is received from a DTLS connection for a long time (where the application decides what "long" means), a transport receiver MAY close the connection. The transport receiver (DTLS server) MUST attempt to initiate an exchange of close_notify alerts with the transport sender before closing the connection. Transport receivers that are unprepared to receive any more data MAY close the connection after sending the close_notify alert.

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.

6.  Congestion Control

Because syslog can generate unlimited amounts of data, transferring this data over UDP is generally problematic, because UDP lacks congestion control mechanisms. Congestion control mechanisms that respond to congestion by reducing traffic rates and establish a degree of fairness between flows that share the same path are vital to the stable operation of the Internet (see [RFC2914] (Floyd, S., “Congestion Control Principles,” September 2000.) and [RFC5405] (Eggert, L. and G. Fairhurst, “Unicast UDP Usage Guidelines for Application Designers,” November 2008.)).

DCCP has congestion control. If DCCP is available, syslog over DTLS over DCCP is RECOMMENDED in preference to syslog over DTLS over UDP. Implementations of syslog over DTLS over DCCP MUST support CCID 3 and SHOULD support CCID 2 to ensure interoperability.

The congestion control considerations from section 4.3 of [RFC5426] (Okmianski, A., “Transmission of Syslog Messages over UDP,” March 2009.) also apply to syslog over DTLS over UDP.

7.  Security Policies

Syslog transport over DTLS has been designed to minimize the security and operational differences for environments where both [RFC5425] (Miao, F., Ma, Y., and J. Salowey, “Transport Layer Security (TLS) Transport Mapping for Syslog,” March 2009.) and syslog over DTLS are supported. The security policies for syslog over DTLS are the same as those described in [RFC5425] (Miao, F., Ma, Y., and J. Salowey, “Transport Layer Security (TLS) Transport Mapping for Syslog,” March 2009.) and all the normative requirements of section 5 of [RFC5425] (Miao, F., Ma, Y., and J. Salowey, “Transport Layer Security (TLS) Transport Mapping for Syslog,” March 2009.) apply.

8.  IANA Consideration

IANA is requested to assign a registered UDP and DCCP port number for syslog over DTLS. The same values as for syslog over TLS (syslog-tls and 6514) are requested. That is, update the registry as follows:

syslog-tls 6514/udp syslog over DTLS [RFCTBD]

syslog-tls 6514/dccp syslog over DTLS [RFCTBD]

IANA is requested to assign the service code SYLG to syslog for use with DCCP. The allocation in the service code registry should be as follows:

1398361159 SYLG Syslog Protocol [RFCTBD]

9.  Security Considerations

The security considerations in [RFC4347] (Rescorla, E. and N. Modadugu, “Datagram Transport Layer Security,” April 2006.), [RFC5246] (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.), [RFC5425] (Miao, F., Ma, Y., and J. Salowey, “Transport Layer Security (TLS) Transport Mapping for Syslog,” March 2009.) and [RFC5280] (Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,” May 2008.) apply to this document.

9.1.  DTLS Renegotiation

TLS and DTLS renegotiation may be vulnerable to attacks described in [RFC5746] (Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, “Transport Layer Security (TLS) Renegotiation Indication Extension,” February 2010.). Although RFC 5746 provides a fix for some of the issues, renegotiation can still cause problems for applications since connection security parameters can change without the application knowing it. Therefore it is RECOMMENDED that renegotiation be disabled for syslog over DTLS. If renegotiation is allowed then the specification in RFC 5746 MUST be followed and the implementation MUST make sure that the connection still has adequate security and that any identities extracted from client and server certificates do not change during renegotiation.

9.2.  Message Loss

The transports described in this document are unreliable. It is possible for messages to be lost or removed by an attacker without the knowledge of the receiver. [RFC5424] (Gerhards, R., “The Syslog Protocol,” March 2009.) notes that implementers who wish a lossless stream should be using tls/tcp as their transport. In addition, the use of signed syslog messages [RFC5848] (Kelsey, J., Callas, J., and A. Clemm, “Signed Syslog Messages,” May 2010.) can also provide an indication of message loss.

9.3.  Private Key Generation

Transport receiver and transport sender implementations often generate their own key pairs. An inadequate random number generator (RNG) or an inadequate pseudo-random number generator (PRNG) to generate these keys can result in little or no security. See [RFC4086] (Eastlake, D., Schiller, J., and S. Crocker, “Randomness Requirements for Security,” June 2005.) for random number generation guidance.

9.4.  Trust Anchor Installation and Storage

Trust anchor installation and storage is critical. Transmission of a trust anchor, especially self-signed certificates used as trust anchors, from transport receiver to transport sender for installation requires an out-of-band step(s). Care must be taken to ensure the installed trust anchor is in fact the correct trust anchor. The fingerprint mechanism in Section 5.3.1 can be used by the transport sender to ensure the transport receiver's self-signed certificate is properly installed. Trust anchor information must be securely stored. Changes to trust anchor information can cause acceptance of certificates that should be rejected.

10.  Acknowledgements

The authors would like to thank Wes Hardaker for his review on this proposal and contributing his valuable suggestions on the use of DTLS. Thanks also to Pasi Eronen, David Harrington, Chris Lonvick, Eliot Lear, Anton Okmyanskiy, Juergen Schoenwaelder, Richard Graveman and members of the syslog working group for their comments, suggestions and review.

11.  References

11.1. Normative References

11.2. Informative References

Authors' Addresses