idnits 2.17.1 draft-ietf-syslog-transport-tls-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 426. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 437. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 444. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 450. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: If a receiver does not support the version in the messages it received, it MAY just save the APPLICATION-DATA in local storage or send a close_notify to signal the closure of the connection. If a sender/relay finds connections are closed just after successful TLS handshake for three times with same transport mapping version, it SHOULD not connect the receiver again with the same transport mapping version. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 21, 2006) is 6365 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) == Outdated reference: A later version (-23) exists of draft-ietf-syslog-protocol-17 ** Obsolete normative reference: RFC 2434 (ref. '3') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3280 (ref. '4') (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 4234 (ref. '5') (Obsoleted by RFC 5234) ** Obsolete normative reference: RFC 4346 (ref. '6') (Obsoleted by RFC 5246) -- Obsolete informational reference (is this intentional?): RFC 3164 (ref. '7') (Obsoleted by RFC 5424) Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Syslog Working Group F. Miao 3 Internet-Draft M. Yuzhi 4 Intended status: Standards Track Huawei Technologies 5 Expires: May 25, 2007 November 21, 2006 7 TLS Transport Mapping for Syslog 8 draft-ietf-syslog-transport-tls-04.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on May 25, 2007. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 This document describes the use of Transport Layer Security (TLS) to 42 provide a secure connection for the transport of Syslog messages. 43 This document describes the security threats to Syslog and how TLS 44 can be used to counter such threats. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Security Requirements for Syslog . . . . . . . . . . . . . . . 3 51 3. TLS to Secure Syslog . . . . . . . . . . . . . . . . . . . . . 4 52 4. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 5 53 4.1. Port Assignment . . . . . . . . . . . . . . . . . . . . . 5 54 4.2. Initiation . . . . . . . . . . . . . . . . . . . . . . . . 5 55 4.3. Sending data . . . . . . . . . . . . . . . . . . . . . . . 6 56 4.3.1. Frame Length . . . . . . . . . . . . . . . . . . . . . 6 57 4.3.2. Version . . . . . . . . . . . . . . . . . . . . . . . 7 58 4.4. Closure . . . . . . . . . . . . . . . . . . . . . . . . . 7 59 5. Security Consideration . . . . . . . . . . . . . . . . . . . . 7 60 5.1. Authentication . . . . . . . . . . . . . . . . . . . . . . 7 61 5.2. Generic Certificate . . . . . . . . . . . . . . . . . . . 8 62 6. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 8 63 6.1. Port Number . . . . . . . . . . . . . . . . . . . . . . . 8 64 6.2. VERSION . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 68 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 70 Intellectual Property and Copyright Statements . . . . . . . . . . 11 72 1. Introduction 74 This document describes the use of Transport Layer Security (TLS [6]) 75 to provide a secure connection for the transport of Syslog messages. 76 This document describes the security threats to Syslog and how TLS 77 can be used to counter such threats. 79 1.1. Terminology 81 The following definitions are used in this document: 83 o A sender is an application that can generate and send a Syslog [2] 84 message to another application. 86 o A receiver is an application that can receive a Syslog message. 88 o A relay is an application that can receive Syslog messages and 89 forward them to another receiver. 91 o A collector is an application that can receive messages but does 92 not relay them to any other receiver. 94 o A TLS client is an application that can initiate a TLS connection 95 by sending a Client Hello to a peer. 97 o A TLS server is an application that can receive a Client Hello 98 from a peer and reply with a Server Hello. 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in RFC 2119 [1]. 104 2. Security Requirements for Syslog 106 Syslog messages may pass several hops to arrive at the intended 107 receiver. Some intermediary networks may not be trusted by the 108 sender/relay, receiver, or all because the network is in a different 109 security domain or at a different security level from the receiver, 110 relay, or sender. Another security concern is that the sender/relay, 111 or receiver itself is in an insecure network. 113 There are several threats to be addressed for Syslog security. The 114 primary threats are: 116 o Masquerade. An unauthorized sender/relay may send messages to a 117 legitimate receiver, or an unauthorized receiver tries to deceive 118 a legitimate sender/relay into sending Syslog messages to it. 120 o Modification. An attacker between the sender/relay and receiver 121 may modify an in-transit Syslog message from the sender/relay and 122 then forward the message to receiver. Such modification may make 123 the receiver misunderstand the message or cause the receiver to 124 behave in undesirable ways. 126 o Disclosure. An unauthorized entity may examine the content of the 127 Syslog messages, gaining unauthorized access to the information. 128 Some data in Syslog messages is sensitive and may be useful to an 129 attacker, such as the password of an authorized administrator or 130 user. 132 The secondary threat is: 134 o Message stream modification. An attacker may delete a Syslog 135 message from a series of messages, replay a message or alter the 136 delivery sequence. Syslog protocol itself is not based on message 137 order, but an event in a Syslog message may relate semantically to 138 events in other messages, so message ordering may be important to 139 understanding a sequence of events. 141 The following threats are deemed to be of lesser importance for 142 Syslog, and are not addressed in this document: 144 o Denial of Service 146 o Traffic Analysis 148 3. TLS to Secure Syslog 150 TLS can be used as a secure transport to counter all the primary and 151 secondary threats to Syslog described in section 2: 153 o Confidentiality to counter disclosure of the message contents 155 o Integrity check to counter modifications to a message 157 o Peer authentication to counter masquerade 159 o Sequence number along with integrity check to counter message 160 stream modification 162 The security service is also applicable to BSD Syslog defined in 163 RFC3164 [7]. But, it is not ensured that the protocol specification 164 defined in this document is applicable to BSD Syslog. 166 4. Protocol Elements 168 4.1. Port Assignment 170 A Syslog sender/relay is always a TLS client and a Syslog receiver is 171 always a TLS server. 173 The TCP port NNN has been allocated as the default port for Syslog 174 over TLS, as defined in this document. 176 Note to RFC Editor: please replace NNN with the IANA-assigned value, 177 and remove this note. 179 4.2. Initiation 181 The sender/relay should initiate a connection to the receiver and 182 then send the TLS Client Hello to begin the TLS handshake. When the 183 TLS handshake has finished the sender/relay may then send the first 184 Syslog message. 186 TLS uses certificate [4] to authenticate the peers. When a sender/ 187 relay authenticates a receiver it MUST validate the certificate. It 188 SHOULD check the common name (CN) of the certificate against the host 189 name of the receiver if it has knowledge of a common name/host name 190 mapping. If the common name does not match the host name, the 191 sender/relay SHOULD send an "access_denied" error alert using the TLS 192 alert protocol to terminate the handshake, and then it SHOULD close 193 the connection. 195 When a receiver authenticates a sender/relay, the receiver MUST 196 validate the certificate. A sender's (or relay's) certificate may 197 be: 199 o An unique certificate, which is issued to a host and whose Common 200 Name may be host name, IP address, MAC, or device ID. 202 o A generic certificate, which is issued to a class of application 203 or device. For example, all cable modems from a vendor may be 204 issued the same generic certificate. 206 A sender/relay certificate may be issued by an operator when a 207 device/application is being provisioned or by a vendor when the 208 device/application is manufactured. This document does not define 209 how the sender/relay certificate is issued. 211 Syslog applications SHOULD be implemented in a manner that permits 212 administrators to select the cryptographic level they desire. It 213 SHOULD be an administrator decision, as a matter of local policy, 214 what security level (e.g. cryptographic algorithms and length of 215 keys) is required. 217 TLS permits the resumption of an earlier TLS session or the use of 218 another active session when a new session is requested, in order to 219 save the expense of another full TLS handshake. The security 220 parameters of the resumed session are reused for the requested 221 session. The security parameters SHOULD be checked against security 222 requirement of requested session to make sure the resumed session 223 provides proper security. 225 4.3. Sending data 227 All Syslog messages MUST be sent as TLS "application data". It is 228 possible that there are multiple Syslog messages in one TLS record, 229 or a Syslog message is transferred in multiple TLS records. The 230 application data is defined with the following ABNF [5] expression: 232 APPLICATION-DATA = VERSION SP 1*SYSLOG-FRAME 234 VERSION = NONZERO-DIGIT *1DIGIT 236 SYSLOG-FRAME = FRAME-LEN SP SYSLOG-MSG 238 FRAME-LEN = NONZERO-DIGIT *DIGIT 240 SP = " " 242 DIGIT = "0" / NONZERO-DIGIT 244 NONZERO-DIGIT = %x31-39 246 SYSLOG-MSG is defined in Syslog [2] protocol. 248 4.3.1. Frame Length 250 The frame length is the octet count of a SYSLOG frame including the 251 FRAME-HEADER and SP parts. A receiver MUST use the frame length 252 field to delimit a Syslog message. There is no upper limit for a 253 frame length per se. However, in order to establish a baseline for 254 interoperability, the specification requires that a receiver MUST be 255 able to process frame with size up to and including 2048 octets. It 256 SHOULD be able to receive frame with size up to and including 8192 257 octets. 259 4.3.2. Version 261 The version is to identify the version of the TLS transport mapping 262 for Syslog, and the version is 1. 264 If a receiver does not support the version in the messages it 265 received, it MAY just save the APPLICATION-DATA in local storage or 266 send a close_notify to signal the closure of the connection. If a 267 sender/relay finds connections are closed just after successful TLS 268 handshake for three times with same transport mapping version, it 269 SHOULD not connect the receiver again with the same transport mapping 270 version. 272 4.4. Closure 274 A Syslog sender/relay MUST close the associated TLS connection if the 275 connection is not expected to deliver Syslog message later. It MUST 276 send a TLS close_notify alert before closing the connection. A 277 sender/relay MAY choose not to wait for the receiver's close_notify 278 alert and simply close the connection, thus generating an incomplete 279 close on the receiver side. Once the receiver gets close_notify from 280 the sender/relay, it MUST reply with a close_notify unless it becomes 281 aware that the connection has already been closed by the sender/relay 282 (e.g., the closure was indicated by TCP). 284 When no data is received from a connection for a long time (where the 285 application decides what "long" means), a receiver MAY close a 286 connection. The receiver MUST attempt to initiate an exchange of 287 close_notify alerts with the sender/relay before closing the 288 connection. Receivers those are unprepared to receive any more data 289 MAY close the connection after sending the close_notify alert, thus 290 generating an incomplete close on the sender/relay side. When the 291 sender/relay has received the close_notify alert from the receiver 292 and still has pending data to send, it SHOULD send the pending data 293 before sending the close_notify alert. 295 5. Security Consideration 297 5.1. Authentication 299 TLS supports three authentication modes: authentication of both 300 parties, server authentication with an unauthenticated client, and 301 total anonymity. 303 TLS authentication and the establishment of secrets is based on 304 certificates and asymmetric cryptography. This makes TLS transport 305 much more expensive than non-TLS plain transport. An attacker may 306 initialize many TLS connections to a receiver as a denial of service 307 attack. Since a receiver may act upon received data, for Syslog over 308 TLS, the receiver SHOULD authenticate the sender/relay to ensure that 309 information received is authentic. 311 When confidentiality is a concern, a sender/relay MUST authenticate 312 the receiver to make sure it is talking to the right peer. 314 5.2. Generic Certificate 316 When a certificate is issued to a class of device or application, the 317 certificate may be shared by multiple hosts. Multiple hosts know the 318 private key of the certificate. When the certificate in one host is 319 compromised, then the certificate for all hosts that share the 320 certificate is compromised. An attacker may impersonate a legitimate 321 sender to send Syslog message to a receiver. 323 6. IANA Consideration 325 6.1. Port Number 327 IANA is requested to assign a TCP port number in the range 1..1023 in 328 the http://www.iana.org/assignments/port-numbers registry which will 329 be the default port for Syslog over TLS, as defined in this document. 331 6.2. VERSION 333 IANA must maintain a registry of VERSION values as described in 334 Section 4.3.2. Version numbers MUST be incremented for any new 335 Syslog TLS transport mapping specification that changes any part of 336 the frame or other parts. Changes include addition or removal of 337 fields or a change of syntax or semantics of existing fields. 339 VERSION numbers must be registered via the Standards Action method as 340 described in RFC2434 [3]. IANA must register the VERSIONs shown in 341 table 1. 343 +---------+---------------------------------+ 344 | VERSION | FORMAT | 345 +---------+---------------------------------+ 346 | 1 | According to this specification | 347 +---------+---------------------------------+ 349 Table 1: Version Number 351 7. Acknowledgments 353 Authors appreciate Eric Rescorla, Anton Okmianski, Rainer Gerhards, 354 Balazs Scheidler and Chris Lonvick for their effort on issues 355 resolving discussion. Authors would also like to appreciate Balazs 356 Scheidler, Tom Petch and other persons for their input on security 357 threats of Syslog. The author would like to acknowledge David 358 Harrington for his detailed reviews of the content and grammar of the 359 document. 361 8. References 363 8.1. Normative References 365 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 366 Levels", BCP 14, RFC 2119, March 1997. 368 [2] Gerhards, R., "The syslog Protocol", 369 draft-ietf-syslog-protocol-17 (work in progress), June 2006. 371 [3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 372 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 374 [4] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 375 Public Key Infrastructure Certificate and Certificate Revocation 376 List (CRL) Profile", RFC 3280, April 2002. 378 [5] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 379 Specifications: ABNF", RFC 4234, October 2005. 381 [6] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) 382 Protocol Version 1.1", RFC 4346, April 2006. 384 8.2. Informative References 386 [7] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, August 2001. 388 Authors' Addresses 390 Miao Fuyou 391 Huawei Technologies 392 No. 3, Xinxi Rd 393 Shangdi Information Industry Base 394 Haidian District, Beijing 100085 395 P. R. China 397 Phone: +86 10 8288 2008 398 Email: miaofy@huawei.com 399 URI: www.huawei.com 401 Ma Yuzhi 402 Huawei Technologies 403 No. 3, Xinxi Rd 404 Shangdi Information Industry Base 405 Haidian District, Beijing 100085 406 P. R. China 408 Phone: +86 10 8288 2008 409 Email: myz@huawei.com 410 URI: www.huawei.com 412 Full Copyright Statement 414 Copyright (C) The Internet Society (2006). 416 This document is subject to the rights, licenses and restrictions 417 contained in BCP 78, and except as set forth therein, the authors 418 retain all their rights. 420 This document and the information contained herein are provided on an 421 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 422 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 423 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 424 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 425 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 426 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 428 Intellectual Property 430 The IETF takes no position regarding the validity or scope of any 431 Intellectual Property Rights or other rights that might be claimed to 432 pertain to the implementation or use of the technology described in 433 this document or the extent to which any license under such rights 434 might or might not be available; nor does it represent that it has 435 made any independent effort to identify any such rights. Information 436 on the procedures with respect to rights in RFC documents can be 437 found in BCP 78 and BCP 79. 439 Copies of IPR disclosures made to the IETF Secretariat and any 440 assurances of licenses to be made available, or the result of an 441 attempt made to obtain a general license or permission for the use of 442 such proprietary rights by implementers or users of this 443 specification can be obtained from the IETF on-line IPR repository at 444 http://www.ietf.org/ipr. 446 The IETF invites any interested party to bring to its attention any 447 copyrights, patents or patent applications, or other proprietary 448 rights that may cover technology that may be required to implement 449 this standard. Please address the information to the IETF at 450 ietf-ipr@ietf.org. 452 Acknowledgment 454 Funding for the RFC Editor function is provided by the IETF 455 Administrative Support Activity (IASA).