idnits 2.17.1 draft-ietf-syslog-dtls-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 (July 8, 2010) is 5040 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 225, but not defined == Missing Reference: 'RFCTBD' is mentioned on line 382, 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: 2 errors (**), 0 flaws (~~), 4 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: January 9, 2011 Engineering Networks Ltd 6 R. Gerhards 7 Adiscon GmbH 8 H. Feng 9 Huaweisymantec Technologies 10 July 8, 2010 12 Datagram Transport Layer Security (DTLS) Transport Mapping for Syslog 13 draft-ietf-syslog-dtls-06.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 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). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on January 9, 2011. 39 Copyright Notice 41 Copyright (c) 2010 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 This document may contain material from IETF Documents or IETF 55 Contributions published or made publicly available before November 56 10, 2008. The person(s) controlling the copyright in some of this 57 material may not have granted the IETF Trust the right to allow 58 modifications of such material outside the IETF Standards Process. 59 Without obtaining an adequate license from the person(s) controlling 60 the copyright in such materials, this document may not be modified 61 outside the IETF Standards Process, and derivative works of it may 62 not be created outside the IETF Standards Process, except to format 63 it for publication as an RFC or to translate it into languages other 64 than English. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 3. Security Requirements for Syslog . . . . . . . . . . . . . . . 6 74 4. Using DTLS to Secure Syslog . . . . . . . . . . . . . . . . . 7 76 5. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 8 77 5.1. Transport . . . . . . . . . . . . . . . . . . . . . . . . 8 78 5.2. Port and Service Code Assignment . . . . . . . . . . . . . 8 79 5.3. Initiation . . . . . . . . . . . . . . . . . . . . . . . . 8 80 5.3.1. Certificate-Based Authentication . . . . . . . . . . . 9 81 5.4. Sending data . . . . . . . . . . . . . . . . . . . . . . . 9 82 5.4.1. Message Size . . . . . . . . . . . . . . . . . . . . . 10 83 5.5. Closure . . . . . . . . . . . . . . . . . . . . . . . . . 10 85 6. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 12 87 7. Security Policies . . . . . . . . . . . . . . . . . . . . . . 13 89 8. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 14 91 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 92 9.1. DTLS Renegotiation . . . . . . . . . . . . . . . . . . . . 15 93 9.2. Message Loss . . . . . . . . . . . . . . . . . . . . . . . 15 94 9.3. Private Key Generation . . . . . . . . . . . . . . . . . . 15 95 9.4. Trust Anchor Installation and Storage . . . . . . . . . . 15 97 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 99 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 100 11.1. Normative References . . . . . . . . . . . . . . . . . . . 17 101 11.2. Informative References . . . . . . . . . . . . . . . . . . 17 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 105 1. Introduction 107 The syslog protocol [RFC5424] is designed to run over different 108 transports for different environments. This document defines the 109 transport of syslog messages over the datagram transport layer 110 security protocol (DTLS) [RFC4347]. 112 The datagram transport layer security protocol (DTLS) [RFC4347] is 113 designed to meet the requirements of applications that need secure 114 datagram transport. DTLS has been mapped onto different transports, 115 including UDP [RFC0768] and DCCP [RFC4340]. This memo defines both 116 options, namely syslog over DTLS over UDP and syslog over DTLS over 117 DCCP. 119 2. Terminology 121 The following definitions from [RFC5424] are used in this document: 123 o An "originator" generates syslog content to be carried in a 124 message. 126 o A "collector" gathers syslog content for further analysis. 128 o A "relay" forwards messages, accepting messages from originators 129 or other relays, and sending them to collectors or other relays. 131 o A "transport sender" passes syslog messages to a specific 132 transport protocol. 134 o A "transport receiver" takes syslog messages from a specific 135 transport protocol. 137 This document adds the following definitions: 139 o A "DTLS client" is an application that can initiate a DTLS Client 140 Hello to a server. 142 o A "DTLS server" is an application that can receive a DTLS Client 143 Hello from a client and reply with a Server Hello. 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in [RFC2119]. 149 3. Security Requirements for Syslog 151 The security requirements for the transport of syslog messages are 152 discussed in Section 2 of [RFC5425]. These also apply to this 153 specification. 155 The following secondary threat is also considered in this document: 157 o Denial of service is discussed in [RFC5424], which states that an 158 attacker may send more messages to a transport receiver than the 159 transport receiver could handle. When using a secure transport 160 protocol handshake, an attacker may use a spoofed IP source to 161 engage the server in a cryptographic handshake to deliberately 162 consume the server's resources. 164 4. Using DTLS to Secure Syslog 166 DTLS can be used as a secure transport to counter all the primary 167 threats to syslog described in [RFC5425]: 169 o Confidentiality to counter disclosure of the message contents. 171 o Integrity checking to counter modifications to a message on a hop- 172 by-hop basis. 174 o Server or mutual authentication to counter masquerade. 176 In addition DTLS also provides: 178 o A cookie exchange mechanism during handshake to counter Denial of 179 Service attacks. 181 o A sequence number in the header to counter replay attacks. 183 Note: This secure transport (i.e., DTLS) only secures syslog 184 transport in a hop-by-hop manner, and is not concerned with the 185 contents of syslog messages. In particular, the authenticated 186 identity of the transport sender (e.g., subject name in the 187 certificate) is not necessarily related to the HOSTNAME field of the 188 syslog message. When authentication of syslog message origin is 189 required, [RFC5848] can be used. 191 5. Protocol Elements 193 5.1. Transport 195 DTLS can run over multiple transports. Implementations of this 196 specification MUST support DTLS over UDP and SHOULD support DTLS over 197 DCCP [RFC5238]. Transports, such as UDP or DCCP do not provide 198 session multiplexing and session-demultiplexing. In such cases, the 199 application implementer provides this functionality by mapping a 200 unique combination of the remote address, remote port number, local 201 address and local port number to a session. 203 Each syslog message is delivered by the DTLS record protocol, which 204 assigns a sequence number to each DTLS record. Although the DTLS 205 implementer may adopt a queue mechanism to resolve reordering, it may 206 not assure that all the messages are delivered in order when mapping 207 on the UDP transport. 209 When DTLS runs over an unreliable transport, such as UDP, reliability 210 is not provided. With DTLS, an originator or relay may not realize 211 that a collector has gone down or lost its DTLS connection state so 212 messages may be lost. 214 Syslog over DTLS over TCP MUST NOT be used. If a secure transport is 215 required with TCP then the appropriate security mechanism is syslog 216 over TLS as described in [RFC5425]. 218 5.2. Port and Service Code Assignment 220 A syslog transport sender is always a DTLS client and a transport 221 receiver is always a DTLS server. 223 The UDP and DCCP port [TBD] has been allocated as the default port 224 for syslog over DTLS as defined in this document. The service code 225 [TBD] has been assigned to syslog. 227 5.3. Initiation 229 The transport sender initiates a DTLS connection by sending a DTLS 230 Client Hello to the transport receiver. Implementations MUST support 231 the denial of service countermeasures defined by DTLS. When these 232 countermeasures are used, the transport receiver responds with a DTLS 233 Hello Verify Request containing a cookie. The transport sender 234 responds with a DTLS Client Hello containing the received cookie 235 which initiates the DTLS handshake. The transport sender MUST NOT 236 send any syslog messages before the DTLS handshake has successfully 237 completed. 239 Implementations MUST support DTLS 1.1 [RFC4347] and MUST support the 240 mandatory to implement cipher suite, which is 241 TLS_RSA_WITH_AES_128_CBC_SHA as specified in [RFC5246]. If 242 additional cipher suites are supported, then implementations MUST NOT 243 negotiate a cipher suite that employs NULL integrity or 244 authentication algorithms. 246 Where privacy is REQUIRED, then implementations must either negotiate 247 a cipher suite that employs a non-NULL encryption algorithm or else 248 achieve privacy by other means, such as a physically secured network. 250 However, as [RFC5424] section 8 points out, 'In most cases, passing 251 clear-text messages is a benefit to the operations staff if they are 252 sniffing the packets from the wire.' and so where privacy is not a 253 requirement, then it is advantageous to use a NULL encryption 254 algorithm. 256 5.3.1. Certificate-Based Authentication 258 The mandatory to implement ciphersuites for DTLS use certificates 259 [RFC5280] to authenticate peers. Both syslog transport sender (DTLS 260 client) and syslog transport receiver (DTLS server) MUST implement 261 certificate-based authentication. This consists of validating the 262 certificate and verifying that the peer has the corresponding private 263 key. The latter part is performed by DTLS. To ensure 264 interoperability between clients and servers, the methods for 265 certificate validation defined in sections 4.2.1 and 4.2.2 of 266 [RFC5425] SHALL be implemented. 268 Both transport receiver and transport sender implementations MUST 269 provide means to generate a key pair and self-signed certificate in 270 case a key pair and certificate are not available through another 271 mechanism. 273 The transport receiver and transport sender SHOULD provide mechanisms 274 to record the certificate or certificate fingerprint used by the 275 remote endpoint for the purpose of correlating an identity with the 276 sent or received data. 278 5.4. Sending data 280 All syslog messages MUST be sent as DTLS "application data". It is 281 possible that multiple syslog messages be contained in one DTLS 282 record, or that a syslog message be transferred in multiple DTLS 283 records. The application data is defined with the following ABNF 284 [RFC5234] expression: 286 APPLICATION-DATA = 1*SYSLOG-FRAME 287 SYSLOG-FRAME = MSG-LEN SP SYSLOG-MSG 289 MSG-LEN = NONZERO-DIGIT *DIGIT 291 SP = %d32 293 NONZERO-DIGIT = %d49-57 295 DIGIT = %d48 / NONZERO-DIGIT 297 SYSLOG-MSG is defined in syslog [RFC5424] protocol. 299 5.4.1. Message Size 301 The message length is the octet count of the SYSLOG-MSG in the 302 SYSLOG-FRAME. A transport receiver MUST use the message length to 303 delimit a syslog message. There is no upper limit for a message 304 length per se. As stated in [RFC4347], a DTLS record MUST NOT span 305 multiple datagrams. When mapping onto different transports, DTLS has 306 different record size limitations. For UDP, see section 3.2 of 307 [RFC5426]. For DCCP, the application implementer SHOULD determine 308 the maximum record size allowed by DTLS protocol running over DCCP, 309 as specified in [RFC4340]. The message size SHOULD NOT exceed the 310 DTLS maximum record size limitation of 2^14 bytes. To be consistent 311 with [RFC5425], in establishing a baseline for interoperability, this 312 specification requires that a transport receiver MUST be able to 313 process messages with a length up to and including 2048 octets. 314 Transport receivers SHOULD be able to process messages with lengths 315 up to and including 8192 octets. 317 See section A.2 of [RFC5424] for implementation guidance on message 318 length, including fragmentation. 320 5.5. Closure 322 A transport sender MUST close the associated DTLS connection if the 323 connection is not expected to deliver any syslog messages later. It 324 MUST send a DTLS close_notify alert before closing the connection. A 325 transport sender (DTLS client) MAY choose to not wait for the 326 transport receiver's close_notify alert and simply close the DTLS 327 connection. Once the transport receiver gets a close_notify from the 328 transport sender, it MUST reply with a close_notify. 330 When no data is received from a DTLS connection for a long time 331 (where the application decides what "long" means), a transport 332 receiver MAY close the connection. The transport receiver (DTLS 333 server) MUST attempt to initiate an exchange of close_notify alerts 334 with the transport sender before closing the connection. Transport 335 receivers that are unprepared to receive any more data MAY close the 336 connection after sending the close_notify alert. 338 Although closure alerts form part of DTLS, they, like all alerts, are 339 not retransmitted by DTLS and so may be lost over an unreliable 340 network. 342 6. Congestion Control 344 Because syslog can generate unlimited amounts of data, transferring 345 this data over UDP is generally problematic, because UDP lacks 346 congestion control mechanisms. Congestion control mechanisms that 347 respond to congestion by reducing traffic rates and establish a 348 degree of fairness between flows that share the same path are vital 349 to the stable operation of the Internet (see [RFC2914] and 350 [RFC5405]). 352 DCCP has congestion control. If DCCP is available, syslog over DTLS 353 over DCCP is RECOMMENDED in preference to syslog over DTLS over UDP. 354 Implementations of syslog over DTLS over DCCP MUST support CCID 3 and 355 SHOULD support CCID 2 to ensure interoperability. 357 The congestion control considerations from section 4.3 of [RFC5426] 358 also apply to syslog over DTLS over UDP. 360 7. Security Policies 362 Syslog transport over DTLS has been designed to minimize the security 363 and operational differences for environments where both [RFC5425] and 364 syslog over DTLS are supported. The security policies for syslog 365 over DTLS are the same as those described in [RFC5425] and all the 366 normative requirements of section 5 of [RFC5425] apply. 368 8. IANA Consideration 370 IANA is requested to assign a registered UDP and DCCP port number for 371 syslog over DTLS. The same values as for syslog over TLS (syslog-tls 372 and 6514) are requested. That is, update the registry as follows: 374 syslog-tls 6514/udp syslog over DTLS [RFCTBD] 376 syslog-tls 6514/dccp syslog over DTLS [RFCTBD] 378 IANA is requested to assign the service code SYLG to syslog for use 379 with DCCP. The allocation in the service code registry should be as 380 follows: 382 1398361159 SYLG Syslog Protocol [RFCTBD] 384 9. Security Considerations 386 The security considerations in [RFC4347], [RFC5246], [RFC5425] and 387 [RFC5280] apply to this document. 389 9.1. DTLS Renegotiation 391 TLS and DTLS renegotiation may be vulnerable to attacks described in 392 [RFC5746]. Although RFC 5746 provides a fix for some of the issues, 393 renegotiation can still cause problems for applications since 394 connection security parameters can change without the application 395 knowing it. Therefore it is RECOMMENDED that renegotiation be 396 disabled for syslog over DTLS. If renegotiation is allowed then the 397 specification in RFC 5746 MUST be followed and the implementation 398 MUST make sure that the connection still has adequate security and 399 that any identities extracted from client and server certificates do 400 not change during renegotiation. 402 9.2. Message Loss 404 The transports described in this document are unreliable. It is 405 possible for messages to be lost or removed by an attacker without 406 the knowledge of the receiver. [RFC5424] notes that implementers who 407 wish a lossless stream should be using tls/tcp as their transport. 408 In addition, the use of signed syslog messages [RFC5848] can also 409 provide an indication of message loss. 411 9.3. Private Key Generation 413 Transport receiver and transport sender implementations often 414 generate their own key pairs. An inadequate random number generator 415 (RNG) or an inadequate pseudo-random number generator (PRNG) to 416 generate these keys can result in little or no security. See 417 [RFC4086] for random number generation guidance. 419 9.4. Trust Anchor Installation and Storage 421 Trust anchor installation and storage is critical. Transmission of a 422 trust anchor, especially self-signed certificates used as trust 423 anchors, from transport receiver to transport sender for installation 424 requires an out-of-band step(s). Care must be taken to ensure the 425 installed trust anchor is in fact the correct trust anchor. The 426 fingerprint mechanism in Section 5.3.1 can be used by the transport 427 sender to ensure the transport receiver's self-signed certificate is 428 properly installed. Trust anchor information must be securely 429 stored. Changes to trust anchor information can cause acceptance of 430 certificates that should be rejected. 432 10. Acknowledgements 434 The authors would like to thank Wes Hardaker for his review on this 435 proposal and contributing his valuable suggestions on the use of 436 DTLS. Thanks also to Pasi Eronen, David Harrington, Chris Lonvick, 437 Eliot Lear, Anton Okmyanskiy, Juergen Schoenwaelder, Richard Graveman 438 and members of the syslog working group for their comments, 439 suggestions and review. 441 11. References 443 11.1. Normative References 445 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 446 August 1980. 448 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 449 Requirement Levels", BCP 14, RFC 2119, March 1997. 451 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 452 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 454 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 455 Security", RFC 4347, April 2006. 457 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 458 Specifications: ABNF", STD 68, RFC 5234, January 2008. 460 [RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over 461 the Datagram Congestion Control Protocol (DCCP)", 462 RFC 5238, May 2008. 464 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 465 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 467 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 468 Housley, R., and W. Polk, "Internet X.509 Public Key 469 Infrastructure Certificate and Certificate Revocation List 470 (CRL) Profile", RFC 5280, May 2008. 472 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009. 474 [RFC5425] Miao, F., Ma, Y., and J. Salowey, "Transport Layer 475 Security (TLS) Transport Mapping for Syslog", RFC 5425, 476 March 2009. 478 [RFC5426] Okmianski, A., "Transmission of Syslog Messages over UDP", 479 RFC 5426, March 2009. 481 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 482 "Transport Layer Security (TLS) Renegotiation Indication 483 Extension", RFC 5746, February 2010. 485 11.2. Informative References 487 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, 488 RFC 2914, September 2000. 490 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 491 Requirements for Security", BCP 106, RFC 4086, June 2005. 493 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 494 for Application Designers", BCP 145, RFC 5405, 495 November 2008. 497 [RFC5848] Kelsey, J., Callas, J., and A. Clemm, "Signed Syslog 498 Messages", RFC 5848, May 2010. 500 Authors' Addresses 502 Joseph Salowey 503 Cisco Systems, Inc. 504 2901 3rd. Ave 505 Seattle, WA 98121 506 USA 508 Email: jsalowey@cisco.com 510 Tom Petch 511 Engineering Networks Ltd 512 18 Parkwood Close 513 Lymm, Cheshire WA13 0NQ 514 UK 516 Email: tomSecurity@network-engineer.co.uk 518 Rainer Gerhards 519 Adiscon GmbH 520 Mozartstrasse 21 521 Grossrinderfeld, BW 97950 522 Germany 524 Email: rgerhards@adiscon.com 526 Hongyan. Feng 527 Huaweisymantec Technologies 528 20245 Steven Creek Blvd 529 Cupertino, CA 95014 531 Email: fhyfeng@gmail.com