summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6012.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6012.txt')
-rw-r--r--doc/rfc/rfc6012.txt675
1 files changed, 675 insertions, 0 deletions
diff --git a/doc/rfc/rfc6012.txt b/doc/rfc/rfc6012.txt
new file mode 100644
index 0000000..c7a8e0c
--- /dev/null
+++ b/doc/rfc/rfc6012.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) J. Salowey
+Request for Comments: 6012 Cisco Systems, Inc.
+Category: Standards Track T. Petch
+ISSN: 2070-1721 Engineering Networks Ltd
+ R. Gerhards
+ Adiscon GmbH
+ H. Feng
+ Huaweisymantec Technologies
+ October 2010
+
+
+ Datagram Transport Layer Security (DTLS) Transport Mapping for Syslog
+
+Abstract
+
+ This document describes the transport of syslog messages over the
+ Datagram Transport Layer Security (DTLS) protocol. It provides a
+ secure transport for syslog messages in cases where a connectionless
+ transport is desired.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc6012.
+
+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.
+
+
+
+Salowey, et al. Standards Track [Page 1]
+
+RFC 6012 DTLS Transport Mapping for Syslog October 2010
+
+
+ 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 3. Security Requirements for Syslog . . . . . . . . . . . . . . . 4
+ 4. Using DTLS to Secure Syslog . . . . . . . . . . . . . . . . . 4
+ 5. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 5
+ 5.1. Transport . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 5.2. Port and Service Code Assignment . . . . . . . . . . . . . 5
+ 5.3. Initiation . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 5.3.1. Certificate-Based Authentication . . . . . . . . . . . 6
+ 5.4. Sending Data . . . . . . . . . . . . . . . . . . . . . . . 6
+ 5.4.1. Message Size . . . . . . . . . . . . . . . . . . . . . 7
+ 5.5. Closure . . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 6. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 8
+ 7. Security Policies . . . . . . . . . . . . . . . . . . . . . . 8
+ 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
+ 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9
+ 9.1. DTLS Renegotiation . . . . . . . . . . . . . . . . . . . . 9
+ 9.2. Message Loss . . . . . . . . . . . . . . . . . . . . . . . 9
+ 9.3. Private Key Generation . . . . . . . . . . . . . . . . . . 9
+ 9.4. Trust Anchor Installation and Storage . . . . . . . . . . 9
+ 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
+ 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
+ 11.1. Normative References . . . . . . . . . . . . . . . . . . . 10
+ 11.2. Informative References . . . . . . . . . . . . . . . . . . 11
+
+
+
+
+
+
+
+
+
+
+
+
+
+Salowey, et al. Standards Track [Page 2]
+
+RFC 6012 DTLS Transport Mapping for Syslog October 2010
+
+
+1. Introduction
+
+ The syslog protocol [RFC5424] is designed to run over different
+ transports for different environments. This document defines the
+ transport of syslog messages over the Datagram Transport Layer
+ Security (DTLS) protocol [RFC4347].
+
+ The Datagram Transport Layer Security (DTLS) protocol [RFC4347] is
+ designed to meet the requirements of applications that need secure
+ datagram transport. DTLS has been mapped onto different transports,
+ including UDP [RFC0768] and the Datagram Congestion Control Protocol
+ (DCCP) [RFC4340]. This memo defines both options, namely syslog over
+ DTLS over UDP, and syslog over DTLS over DCCP.
+
+2. Terminology
+
+ The following definitions from [RFC5424] 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.
+
+ This document adds the following definitions:
+
+ o A "DTLS client" is an application that can initiate a DTLS Client
+ Hello to a server.
+
+ o 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].
+
+
+
+
+
+
+
+
+Salowey, et al. Standards Track [Page 3]
+
+RFC 6012 DTLS Transport Mapping for Syslog October 2010
+
+
+3. Security Requirements for Syslog
+
+ The security requirements for the transport of syslog messages are
+ discussed in Section 2 of [RFC5425]. These also apply to this
+ specification.
+
+ The following secondary threat is also considered in this document:
+
+ o Denial of service is discussed in [RFC5424], 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]:
+
+ 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.
+
+ In addition, DTLS also provides:
+
+ o A cookie exchange mechanism during handshake to counter Denial of
+ Service attacks.
+
+ o 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] can be used.
+
+
+
+
+
+
+
+
+
+
+Salowey, et al. Standards Track [Page 4]
+
+RFC 6012 DTLS Transport Mapping for Syslog October 2010
+
+
+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]. 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 Transport Layer Security (TLS) as described in [RFC5425].
+
+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 6514 has been allocated as the default port for
+ syslog over DTLS as defined in this document. The service code SYLG
+ (1398361159) 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.
+
+
+
+
+Salowey, et al. Standards Track [Page 5]
+
+RFC 6012 DTLS Transport Mapping for Syslog October 2010
+
+
+ Implementations MUST support DTLS 1.0 [RFC4347] and MUST support the
+ mandatory to implement cipher suite, which is
+ TLS_RSA_WITH_AES_128_CBC_SHA as specified in [RFC5246]. 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], 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 cipher suites for DTLS use certificates
+ [RFC5280] to authenticate peers. Both the syslog transport sender
+ (DTLS client) and the 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] 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
+ [RFC5234] expression:
+
+
+
+
+
+Salowey, et al. Standards Track [Page 6]
+
+RFC 6012 DTLS Transport Mapping for Syslog October 2010
+
+
+ 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 the syslog [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], 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]. For DCCP, the application implementer SHOULD determine
+ the maximum record size allowed by the DTLS protocol running over
+ DCCP, as specified in [RFC4340]. The message size SHOULD NOT exceed
+ the DTLS maximum record size limitation of 2^14 bytes. To be
+ consistent with [RFC5425], 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 Appendix A.2 of [RFC5424] 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
+
+
+
+Salowey, et al. Standards Track [Page 7]
+
+RFC 6012 DTLS Transport Mapping for Syslog October 2010
+
+
+ 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 are a component of TLS and so 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 establishing a
+ degree of fairness between flows that share the same path are vital
+ to the stable operation of the Internet (see [RFC2914] and
+ [RFC5405]).
+
+ 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 Congestion
+ Control Identifier (CCID) 3 and SHOULD support CCID 2 to ensure
+ interoperability.
+
+ The congestion control considerations from Section 4.3 of [RFC5426]
+ 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 syslog over
+ TLS [RFC5425] and syslog over DTLS are supported. The security
+ policies for syslog over DTLS are the same as those described in
+ [RFC5425], and all the normative requirements of Section 5 of
+ [RFC5425] apply.
+
+8. IANA Considerations
+
+ IANA has assigned a registered UDP and DCCP port number for syslog
+ over DTLS. The values are the same as for syslog over TLS. That is,
+ the registry has been updated as follows:
+
+ syslog-tls 6514/udp syslog over DTLS [RFC6012]
+ syslog-tls 6514/dccp syslog over DTLS [RFC6012]
+
+
+
+
+
+
+Salowey, et al. Standards Track [Page 8]
+
+RFC 6012 DTLS Transport Mapping for Syslog October 2010
+
+
+ IANA has assigned the service code SYLG to syslog for use with DCCP.
+ The allocation in the Service Code subregistry of the Datagram
+ Congestion Control Protocol (DCCP) Parameters registry is as follows:
+
+ 1398361159 SYLG Syslog Protocol [RFC6012]
+
+9. Security Considerations
+
+ The security considerations in [RFC4347], [RFC5246], [RFC5425], and
+ [RFC5280] apply to this document.
+
+9.1. DTLS Renegotiation
+
+ TLS and DTLS renegotiation may be vulnerable to attacks described in
+ [RFC5746]. 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] 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] 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] 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 one or more out-of-band steps. Care must be taken to ensure
+ the installed trust anchor is in fact the correct trust anchor. The
+
+
+
+Salowey, et al. Standards Track [Page 9]
+
+RFC 6012 DTLS Transport Mapping for Syslog October 2010
+
+
+ fingerprint mechanism mentioned 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 of this
+ proposal and for 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, the members of the syslog working group, and the members of
+ the IESG for their review, comments, and suggestions.
+
+11. References
+
+11.1. Normative References
+
+ [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+ August 1980.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
+ Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
+
+ [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
+ Security", RFC 4347, April 2006.
+
+ [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", STD 68, RFC 5234, January 2008.
+
+ [RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over
+ the Datagram Congestion Control Protocol (DCCP)",
+ RFC 5238, May 2008.
+
+ [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
+ (TLS) Protocol Version 1.2", RFC 5246, August 2008.
+
+ [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", RFC 5280, May 2008.
+
+ [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
+
+
+
+
+Salowey, et al. Standards Track [Page 10]
+
+RFC 6012 DTLS Transport Mapping for Syslog October 2010
+
+
+ [RFC5425] Miao, F., Ma, Y., and J. Salowey, "Transport Layer
+ Security (TLS) Transport Mapping for Syslog", RFC 5425,
+ March 2009.
+
+ [RFC5426] Okmianski, A., "Transmission of Syslog Messages over UDP",
+ RFC 5426, March 2009.
+
+ [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov,
+ <"Transport Layer Security (TLS) Renegotiation Indication
+ Extension", RFC 5746, February 2010.
+
+11.2. Informative References
+
+ [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41,
+ RFC 2914, September 2000.
+
+ [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
+ Requirements for Security", BCP 106, RFC 4086, June 2005.
+
+ [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines
+ for Application Designers", BCP 145, RFC 5405,
+ November 2008.
+
+ [RFC5848] Kelsey, J., Callas, J., and A. Clemm, "Signed Syslog
+ Messages", RFC 5848, May 2010.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Salowey, et al. Standards Track [Page 11]
+
+RFC 6012 DTLS Transport Mapping for Syslog October 2010
+
+
+Authors' Addresses
+
+ Joseph Salowey
+ Cisco Systems, Inc.
+ 2901 3rd Ave.
+ Seattle, WA 98121
+ USA
+
+ EMail: jsalowey@cisco.com
+
+
+ Tom Petch
+ Engineering Networks Ltd
+ 18 Parkwood Close
+ Lymm, Cheshire WA13 0NQ
+ UK
+
+ EMail: tomSecurity@network-engineer.co.uk
+
+
+ Rainer Gerhards
+ Adiscon GmbH
+ Mozartstrasse 21
+ Grossrinderfeld, BW 97950
+ Germany
+
+ EMail: rgerhards@adiscon.com
+
+
+ Hongyan Feng
+ Huaweisymantec Technologies
+ 20245 Stevens Creek Blvd.
+ Cupertino, CA 95014
+
+ EMail: fhyfeng@gmail.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Salowey, et al. Standards Track [Page 12]
+