idnits 2.17.1 draft-ietf-syslog-dtls-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 8, 2010) is 5164 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TBD' is mentioned on line 226, but not defined ** Obsolete normative reference: RFC 4347 (Obsoleted by RFC 6347) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5405 (Obsoleted by RFC 8085) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Salowey 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track T. Petch 5 Expires: September 9, 2010 Engineering Networks Ltd 6 R. Gerhards 7 Adiscon GmbH 8 H. Feng 9 Huaweisymantec Technologies 10 March 8, 2010 12 Datagram Transport Layer Security (DTLS) Transport Mapping for Syslog 13 draft-ietf-syslog-dtls-03.txt 15 Abstract 17 This document describes the transport of syslog messages over DTLS 18 (Datagram Transport Level Security). It provides a secure transport 19 for syslog messages in cases where a connection-less transport is 20 desired. 22 Status of this Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on September 9, 2010. 45 Copyright Notice 47 Copyright (c) 2010 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the BSD License. 60 This document may contain material from IETF Documents or IETF 61 Contributions published or made publicly available before November 62 10, 2008. The person(s) controlling the copyright in some of this 63 material may not have granted the IETF Trust the right to allow 64 modifications of such material outside the IETF Standards Process. 65 Without obtaining an adequate license from the person(s) controlling 66 the copyright in such materials, this document may not be modified 67 outside the IETF Standards Process, and derivative works of it may 68 not be created outside the IETF Standards Process, except to format 69 it for publication as an RFC or to translate it into languages other 70 than English. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 78 3. Security Requirements for Syslog . . . . . . . . . . . . . . . 6 80 4. Using DTLS to Secure Syslog . . . . . . . . . . . . . . . . . 7 82 5. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 8 83 5.1. Transport . . . . . . . . . . . . . . . . . . . . . . . . 8 84 5.2. Port Assignment . . . . . . . . . . . . . . . . . . . . . 8 85 5.3. Initiation . . . . . . . . . . . . . . . . . . . . . . . . 8 86 5.3.1. Certificate-Based Authentication . . . . . . . . . . . 9 87 5.4. Sending data . . . . . . . . . . . . . . . . . . . . . . . 9 88 5.4.1. Message Size . . . . . . . . . . . . . . . . . . . . . 10 89 5.5. Closure . . . . . . . . . . . . . . . . . . . . . . . . . 10 91 6. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 11 93 7. Security Policies . . . . . . . . . . . . . . . . . . . . . . 12 95 8. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 13 97 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 98 9.1. DTLS Renegotiation . . . . . . . . . . . . . . . . . . . . 14 100 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 102 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 103 11.1. Normative References . . . . . . . . . . . . . . . . . . . 16 104 11.2. Informative References . . . . . . . . . . . . . . . . . . 16 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 108 1. Introduction 110 The syslog protocol [RFC5424] is designed to run over different 111 transports for different environments. This document defines the 112 transport of syslog messages over the datagram transport layer 113 security protocol (DTLS) [RFC4347]. 115 The datagram transport layer security protocol (DTLS) [RFC4347] is 116 designed to meet the requirements of applications that need secure 117 datagram transport. DTLS has been mapped onto different transports, 118 including UDP [RFC0768] and DCCP [RFC4340]. This memo defines both 119 options, namely syslog over DTLS over UDP and syslog over DTLS over 120 DCCP. 122 2. Terminology 124 The following definitions from [RFC5424] are used in this document: 126 o An "originator" generates syslog content to be carried in a 127 message. 129 o A "collector" gathers syslog content for further analysis. 131 o A "relay" forwards messages, accepting messages from originators 132 or other relays, and sending them to collectors or other relays. 134 o A "transport sender" passes syslog messages to a specific 135 transport protocol. 137 o A "transport receiver" takes syslog messages from a specific 138 transport protocol. 140 This document adds the following definitions: 142 o A "DTLS client" is an application that can initiate a DTLS Client 143 Hello to a server. 145 o A "DTLS server" is an application that can receive a DTLS Client 146 Hello from a client and reply with a Server Hello. 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 150 document are to be interpreted as described in [RFC2119]. 152 3. Security Requirements for Syslog 154 The security requirements for the transport of syslog messages are 155 discussed in Section 2 of [RFC5425]. These also apply to this 156 specification. 158 The following secondary threat is also considered in this document: 160 o Denial of Service Denial of service is discussed in [RFC5424], 161 which states that an attacker may send more messages to a 162 transport receiver than the transport receiver could handle. When 163 using a secure transport protocol handshake, an attacker may use a 164 spoofed IP source to engage the server in a cryptographic 165 handshake to deliberately consume the server's resources. 167 4. Using DTLS to Secure Syslog 169 DTLS can be used as a secure transport to counter all the primary 170 threats to syslog described in [RFC5425]: 172 o Confidentiality to counter disclosure of the message contents. 174 o Integrity checking to counter modifications to a message on a hop- 175 by-hop basis. 177 o Server or mutual authentication to counter masquerade. 179 In addition DTLS also provides: 181 o A cookie exchange mechanism during handshake to counter Denial of 182 Service attacks. 184 o A sequence number in the header to counter replay attacks. 186 Note: This secure transport (i.e., DTLS) only secures syslog 187 transport in a hop-by-hop manner, and is not concerned with the 188 contents of syslog messages. In particular, the authenticated 189 identity of the transport sender (e.g., subject name in the 190 certificate) is not necessarily related to the HOSTNAME field of the 191 syslog message. When authentication of syslog message origin is 192 required, [I-D.ietf-syslog-sign] can be used. 194 5. Protocol Elements 196 5.1. Transport 198 DTLS can run over multiple transports. Implementations of this 199 specification MUST support DTLS over UDP and SHOULD support DTLS over 200 DCCP [RFC5238]. Transports, such as UDP or DCCP do not provide 201 session multiplexing and session-demultiplexing. In such cases, the 202 application implementer provides this functionality by mapping a 203 unique combination of the remote address, remote port number, local 204 address and local port number to a session. 206 Each syslog message is delivered by the DTLS record protocol, which 207 assigns a sequence number to each DTLS record. Although the DTLS 208 implementer may adopt a queue mechanism to resolve reordering, it may 209 not assure that all the messages are delivered in order when mapping 210 on the UDP transport. 212 When DTLS runs over an unreliable transport, such as UDP, reliability 213 is not provided. With DTLS, an originator or relay may not realize 214 that a collector has gone down or lost its DTLS connection state so 215 messages may be lost. 217 Syslog over DTLS over TCP MUST NOT be used. If a secure transport is 218 required with TCP then the appropriate security mechanism is syslog 219 over TLS as described in [RFC5425]. 221 5.2. Port Assignment 223 A syslog transport sender is always a DTLS client and a transport 224 receiver is always a DTLS server. 226 The UDP and DCCP port [TBD] has been allocated as the default port 227 for syslog over DTLS as defined in this document. 229 5.3. Initiation 231 The transport sender initiates a DTLS connection by sending a DTLS 232 Client Hello to the transport receiver. Implementations MUST support 233 the denial of service countermeasures defined by DTLS. When these 234 countermeasures are enabled, the transport receiver responds with a 235 DTLS Hello Verify Request containing a cookie. The transport sender 236 responds with a DTLS Client Hello containing the received cookie 237 which initiates the DTLS handshake. When the DTLS handshake has 238 finished, the transport sender MAY then send the first syslog 239 message. 241 Implementations MUST support DTLS 1.1 [RFC4347] and MUST support the 242 mandatory to implement cipher suite, which is 243 TLS_RSA_WITH_AES_128_CBC_SHA. 245 5.3.1. Certificate-Based Authentication 247 The mandatory to implement ciphersuites for DTLS use certificates 248 [RFC5280] to authenticate peers. Both syslog transport sender (DTLS 249 client) and syslog transport receiver (DTLS server) MUST implement 250 certificate-based authentication. This consists of validating the 251 certificate and verifying that the peer has the corresponding private 252 key. The latter part is performed by DTLS. To ensure 253 interoperability between clients and servers, the methods for 254 certificate validation defined in sections 4.2.1 and 4.2.2 of 255 [RFC5425] SHALL be implemented. 257 Both transport receiver and transport sender implementations MUST 258 provide means to generate a key pair and self-signed certificate in 259 case a key pair and certificate are not available through another 260 mechanism. 262 The transport receiver and transport sender SHOULD provide mechanisms 263 to record the certificate or certificate fingerprint used by the 264 remote endpoint for the purpose of correlating an identity with the 265 sent or received data. 267 5.4. Sending data 269 All syslog messages MUST be sent as DTLS "application data". It is 270 possible that multiple syslog messages be contained in one DTLS 271 record, or that a syslog message be transferred in multiple DTLS 272 records. The application data is defined with the following ABNF 273 [RFC5234] expression: 275 APPLICATION-DATA = 1*SYSLOG-FRAME 277 SYSLOG-FRAME = MSG-LEN SP SYSLOG-MSG 279 MSG-LEN = NONZERO-DIGIT *DIGIT 281 SP = %d32 283 NONZERO-DIGIT = %d49-57 285 DIGIT = %d48 / NONZERO-DIGIT 287 SYSLOG-MSG is defined in syslog [RFC5424] protocol. 289 5.4.1. Message Size 291 The message length is the octet count of the SYSLOG-MSG in the 292 SYSLOG-FRAME. A transport receiver MUST use the message length to 293 delimit a syslog message. There is no upper limit for a message 294 length per se. As stated in [RFC4347], each DTLS record MUST fit 295 within a single DTLS datagram. When mapping onto different 296 transports, DTLS has different record size limitations. The 297 application implementer SHOULD determine the maximum record size 298 allowed by DTLS protocol running over the transport in use. The 299 message size SHOULD NOT exceed the DTLS maximum record size 300 limitation of 2^14 bytes. To be consistent with RFC 5425, in 301 establishing a baseline for interoperability, this specification 302 requires that a transport receiver MUST be able to process messages 303 with a length up to and including 2048 octets. Transport receivers 304 SHOULD be able to process messages with lengths up to and including 305 8192 octets. 307 5.5. Closure 309 A transport sender MUST close the associated DTLS connection if the 310 connection is not expected to deliver any syslog messages later. It 311 MUST send a DTLS close_notify alert before closing the connection. A 312 transport sender (DTLS client) MAY choose to not wait for the 313 transport receiver's close_notify alert and simply close the DTLS 314 connection. Once the transport receiver gets a close_notify from the 315 transport sender, it MUST reply with a close_notify. 317 When no data is received from a DTLS connection for a long time 318 (where the application decides what "long" means), a transport 319 receiver MAY close the connection. The transport receiver (DTLS 320 server) MUST attempt to initiate an exchange of close_notify alerts 321 with the transport sender before closing the connection. Transport 322 receivers that are unprepared to receive any more data MAY close the 323 connection after sending the close_notify alert. 325 Although closure alerts form part of DTLS, they, like all alerts, are 326 not retransmitted by DTLS and so may be lost over an unreliable 327 network. 329 6. Congestion Control 331 Because syslog can generate unlimited amounts of data, transferring 332 this data over UDP is generally problematic, because UDP lacks 333 congestion control mechanisms. Congestion control mechanisms that 334 respond to congestion by reducing traffic rates and establish a 335 degree of fairness between flows that share the same path are vital 336 to the stable operation of the Internet (see [RFC2914] and 337 [RFC5405]). 339 DCCP has congestion control. For this reason the syslog over DTLS 340 over DCCP option is recommended in preference to the syslog over the 341 DTLS over UDP option. 343 The congestion control considerations from section 4.3 of [RFC5426] 344 also apply to syslog over DTLS over udp. 346 7. Security Policies 348 Syslog transport over DTLS has been designed to minimize the security 349 and operational differences for environments where both [RFC5425] and 350 syslog over DTLS are supported. The security policies for syslog 351 over DTLS are the same as those described in [RFC5425]. 353 8. IANA Consideration 355 IANA is requested to assign a registered UDP and DCCP port number for 356 syslog over DTLS. The same value as for syslog over TLS (6514) is 357 requested. 359 9. Security Considerations 361 The security considerations in [RFC5425], [RFC5246] and [RFC4347] 362 apply to this document. 364 9.1. DTLS Renegotiation 366 TLS and DTLS renegotiation may be vulnerable to attacks described in 367 [RFC5746]. Although RFC 5746 provides a fix for some of the issues, 368 renegotiation can still cause problems for applications since 369 connection security parameters can change without the application 370 knowing it. Therefore it is RECOMMENDED that renegotiation be 371 disabled for syslog over DTLS. If, for some reason, renegotiation is 372 allowed then the specification in RFC 5746 MUST be followed and the 373 implementation MUST make sure that the connection security parameters 374 do not change during renegotiation. 376 10. Acknowledgements 378 The authors would like to thank Wes Hardaker for his review on this 379 proposal and contributing his valuable suggestions on the use of 380 DTLS. Thanks also to Pasi Eronen, David Harrington, Chris Lonvick, 381 Eliot Lear, Anton Okmyanskiy, Juergen Schoenwaelder, Richard Graveman 382 and members of the syslog working group for their comments, 383 suggestions and review. 385 11. References 387 11.1. Normative References 389 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 390 August 1980. 392 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 393 Requirement Levels", BCP 14, RFC 2119, March 1997. 395 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 396 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 398 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 399 Security", RFC 4347, April 2006. 401 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 402 Specifications: ABNF", STD 68, RFC 5234, January 2008. 404 [RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over 405 the Datagram Congestion Control Protocol (DCCP)", 406 RFC 5238, May 2008. 408 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 409 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 411 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 412 Housley, R., and W. Polk, "Internet X.509 Public Key 413 Infrastructure Certificate and Certificate Revocation List 414 (CRL) Profile", RFC 5280, May 2008. 416 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009. 418 [RFC5425] Miao, F., Ma, Y., and J. Salowey, "Transport Layer 419 Security (TLS) Transport Mapping for Syslog", RFC 5425, 420 March 2009. 422 [RFC5426] Okmianski, A., "Transmission of Syslog Messages over UDP", 423 RFC 5426, March 2009. 425 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 426 "Transport Layer Security (TLS) Renegotiation Indication 427 Extension", RFC 5746, February 2010. 429 11.2. Informative References 431 [I-D.ietf-syslog-sign] 432 Kelsey, J., Callas, J., and A. Clemm, "Signed syslog 433 Messages", draft-ietf-syslog-sign-29 (work in progress), 434 December 2009. 436 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, 437 RFC 2914, September 2000. 439 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 440 for Application Designers", BCP 145, RFC 5405, 441 November 2008. 443 Authors' Addresses 445 Joseph Salowey 446 Cisco Systems, Inc. 447 2901 3rd. Ave 448 Seattle, WA 98121 449 USA 451 Email: jsalowey@cisco.com 453 Tom Petch 454 Engineering Networks Ltd 455 18 Parkwood Close 456 Lymm, Cheshire WA13 0NQ 457 UK 459 Email: tomSecurity@network-engineer.co.uk 461 Rainer Gerhards 462 Adiscon GmbH 463 Mozartstrasse 21 464 Grossrinderfeld, BW 97950 465 Germany 467 Email: rgerhards@adiscon.com 469 Hongyan. Feng 470 Huaweisymantec Technologies 471 20245 Steven Creek Blvd 472 Cupertino, CA 95014 474 Email: fhyfeng@gmail.com