idnits 2.17.1 draft-ietf-syslog-transport-tls-03.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 455. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 466. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 473. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 479. ** 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 -- 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 (August 27, 2006) is 6450 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-23) exists of draft-ietf-syslog-protocol-17 ** Obsolete normative reference: RFC 2234 (ref. '3') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2246 (ref. '4') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2434 (ref. '5') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3280 (ref. '6') (Obsoleted by RFC 5280) -- Obsolete informational reference (is this intentional?): RFC 3164 (ref. '7') (Obsoleted by RFC 5424) Summary: 7 errors (**), 0 flaws (~~), 2 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: Informational Huawei Technologies 5 Expires: February 28, 2007 August 27, 2006 7 TLS Transport Mapping for SYSLOG 8 draft-ietf-syslog-transport-tls-03.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 February 28, 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 Fundmentals . . . . . . . . . . . . . . . . . . . . . . . 4 52 3.1. How TLS works . . . . . . . . . . . . . . . . . . . . . . 4 53 3.2. Security Properties . . . . . . . . . . . . . . . . . . . 4 54 4. TLS to secure Syslog . . . . . . . . . . . . . . . . . . . . . 5 55 5. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 5 56 5.1. Port Assignment . . . . . . . . . . . . . . . . . . . . . 5 57 5.2. Initiation . . . . . . . . . . . . . . . . . . . . . . . . 6 58 5.3. Sending data . . . . . . . . . . . . . . . . . . . . . . . 7 59 5.3.1. Frame Length . . . . . . . . . . . . . . . . . . . . . 7 60 5.3.2. Version . . . . . . . . . . . . . . . . . . . . . . . 7 61 5.4. Closure . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 6. Security Consideration . . . . . . . . . . . . . . . . . . . . 8 63 6.1. Authentication . . . . . . . . . . . . . . . . . . . . . . 8 64 6.2. Generic Certificate . . . . . . . . . . . . . . . . . . . 8 65 7. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 9 66 7.1. Port Number . . . . . . . . . . . . . . . . . . . . . . . 9 67 7.2. VERSION . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 71 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 73 Intellectual Property and Copyright Statements . . . . . . . . . . 11 75 1. Introduction 77 This document describes the use of Transport Layer Security (TLS) to 78 provide a secure connection for the transport of syslog messages. 79 This document describes the security threats to Syslog and how TLS 80 can be used to counter such threats. 82 1.1. Terminology 84 The following definitions are used in this document: 86 o A sender is an application that can generate and send a Syslog [2] 87 message to another application. 89 o A receiver is an application that can receive a Syslog message. 91 o A relay is an application that can receive syslog messages and 92 forward them to another receiver. 94 o A collector is an application that can receive messages but does 95 not relay them to any other receiver. 97 o A TLS client is an application that can initiate a TLS connection 98 by sending a Client Hello to a peer. 100 o A TLS server is an application that can receive a Client Hello 101 from a peer and reply with a Server Hello. 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in RFC 2119 [1]. 107 2. Security Requirements for Syslog 109 Syslog messages may pass several hops to arrive at the intended 110 receiver. Some intermediary networks may not be trusted by the 111 sender/relay, receiver, or all because the network is in a different 112 security domain or at a different security level from the receiver, 113 relay, or sender. Another security concern is that the sender/relay, 114 or receiver itself is in an insecure network. 116 There are several threats to be addressed for Syslog security. The 117 primary threats are: 119 o Masquerade. An unauthorized sender/relay may send messages to a 120 legitimate receiver, or an unauthorized receiver tries to deceive 121 a legitimate sender/relay into sending Syslog messages to it. 123 o Modification. An attacker between the sender/relay and receiver 124 may modify an in-transit Syslog message from the sender/relay and 125 then forward the message to receiver. Such modification may make 126 the receiver misunderstand the message or cause the receiver to 127 behave in undesirable ways. 129 o Disclosure. An unauthorized entity may examine the content of the 130 Syslog messages, gaining unauthorized access to the information. 131 Some data in Syslog messages is sensitive and may be useful to an 132 attacker, such as the password of an authorized administrator or 133 user. 135 The secondary threat is: 137 o Message stream modification. An attacker may delete a Syslog 138 message from a series of messages, replay a message or alter the 139 delivery sequence. Syslog protocol itself is not based on message 140 order, but an event in a Syslog message may relate semantically to 141 events in other messages, so message ordering may be important to 142 understanding a sequence of events. 144 The following threats are deemed to be of lesser importance for 145 syslog, and are not addressed in this document: 147 o Denial of Service 149 o Traffic Analysis 151 3. TLS Fundmentals 153 3.1. How TLS works 155 TLS [4] establishes a private end-to-end connection, optionally 156 including strong mutual authentication, using a variety of 157 cryptosystems. Initially, a handshake phase uses three subprotocols 158 to set up a record layer, authenticate endpoints, set parameters, and 159 report errors. Then, there is an ongoing layered record protocol 160 that handles encryption and message integrity for the remainder of 161 the connection. An application data protocol, such as Syslog, is 162 layered on the record protocol. 164 3.2. Security Properties 166 The TLS record protocol is used to encapsulate various higher level 167 protocols. It provides connection security with confidentiality, 168 integrity, authentication, and replay prevention. 170 Confidentiality is provided using symmetric cryptography for data 171 encryption. TLS supports both stream cipher and block cipher. The 172 key for encryption is derived from a secret established by the 173 handshake protocol. When there is an eavesdropper in the middle, the 174 secret is kept private if at least one session identifier is 175 authenticated during hanshake. 177 Integrity is provided by using a message authentication code to check 178 the integrity of a message. Modification without the appropriate key 179 is detectable. 181 Authentication is provided by a handshake protocol. The peer's 182 identity is authenticated using asymmetric cryptography. 184 Replay prevention is provided by using a Sequence Number in each TLS 185 record that is used to detect a missing record, the replay of a 186 record, or alteration of the delivery sequence. 188 4. TLS to secure Syslog 190 TLS can be used as a secure transport to counter all the primary and 191 secondary threats to Syslog described in section 2: 193 o Confidentiality to counter disclosure of the message contents 195 o Integrity check to counter modifications to a message 197 o Peer authentication to counter masquerade 199 o Sequence number along with integrity check to counter message 200 stream modification 202 The security service is also applicable to BSD Syslog defined in 203 RFC3164 [7]. But, it is not ensured that the protocol specification 204 defined in this document is applicable to BSD Syslog. 206 5. Protocol Elements 208 5.1. Port Assignment 210 A Syslog sender/relay is always a TLS client and a Syslog receiver is 211 always a TLS server. 213 The TCP port NNN has been allocated as the default port for Syslog 214 over TLS, as defined in this document. 216 Note to RFC Editor: please replace NNN with the IANA-assigned value, 217 and remove this note. 219 5.2. Initiation 221 The sender/relay should initiate a connection to the receiver and 222 then send the TLS Client Hello to begin the TLS handshake. When the 223 TLS handshake has finished the sender/relay may then send the first 224 Syslog message. 226 TLS uses certificate [6] to authenticate the peers. When a sender/ 227 relay authenticates a receiver it MUST validate the certificate. It 228 SHOULD check the common name(CN) of the certificate against the host 229 name of the receiver if it has knowledge of a common name/host name 230 mapping. If the common name does not match the host name, the 231 sender/relay SHOULD send an "access_denied" error alert using the TLS 232 alert protocol to terminate the handshake, and then it SHOULD close 233 the connection. 235 When a receiver authenticates a sender/relay, the receiver MUST 236 validate the certificate. A sender's (or relay's) certificate may 237 be: 239 o A unique certificate, which is issued to a host and whose Common 240 Name may be host name, IP address, MAC, or device ID. 242 o A generic certificate, which is issued to a class of application 243 or device. For example, all cable modems from a vendor may be 244 issued the same generic certificate. 246 A sender/relay certificate may be issued by an operator when a 247 device/application is being provisioned or by a vendor when the 248 device/application is manufactured. This document does not define 249 how the sender/relay certificate is issued. 251 Syslog applications SHOULD be implemented in a manner that permits 252 administrators to select the cryptographic level they desire. It 253 SHOULD be an administrator decision, as a matter of local policy, 254 what security level (e.g. cryptographic algorithms and length of 255 keys) is required. 257 TLS permits the resumption of an earlier TLS session or the use of 258 another active session when a new session is requested, in order to 259 save the expense of another full TLS handshake. The security 260 parameters of the resumed session are reused for the requested 261 session. The security parameters SHOULD be checked against security 262 requirement of requested session to make sure the resumed session 263 provides proper security. 265 5.3. Sending data 267 All Syslog messages MUST be sent as TLS "application data". It is 268 possible that there are multiple Syslog messages in one TLS record, 269 or a Syslog message is transferred in multiple TLS record. The 270 application data is defined with the following ABNF [3] expression: 272 APPLICATION-DATA = 1*SYSLOG-FRAME 274 SYSLOG-FRAME = FRAME-HEADER SP SYSLOG-MSG 276 FRAME-HEADER = VERSION SP FRAME-LEN 278 VERSION = NONZERO-DIGIT 0*DIGIT 280 FRAME-LEN = NONZERO-DIGIT 0*DIGIT 282 SP = %d32 284 DIGIT = %d48 / NONZERO-DIGIT 286 NONZERO-DIGIT = %d49-57 288 SYSLOG-MSG is defined in Syslog [2] protocol. 290 5.3.1. Frame Length 292 The frame length is the octet count of a SYSLOG frame including the 293 FRAME-HEADER and SP parts. A receiver MUST use the frame length 294 field to delimit a syslog message. There is not upper limit for a 295 frame length per se. However, in order to establish a baseline for 296 interoperability, the specification requires that a receiver MUST be 297 able to process frame with size up to and including 2048 octects. It 298 SHOULD be able to reveive frame with size up to and including 8192 299 octects. 301 5.3.2. Version 303 The version is to identify the version of the TLS transport mapping 304 for Syslog, and the version is 1. 306 5.4. Closure 308 A Syslog sender/relay MUST close the associated TLS connection if the 309 connection is not expected to deliver Syslog message later. It MUST 310 send a TLS closure_notify alert before closing the connection. A 311 sender/relay MAY choose not to wait for the receiver's closure_notify 312 alert and simply close the connection, thus generating an incomplete 313 close on the receiver side. Once the receiver gets closure_notify 314 from the sender/relay, it MUST reply with a closure_notify unless it 315 becomes aware that the connection has already been closed by the 316 sender/relay(e.g., the closure was indicated by TCP). 318 When no data is received from a connection for a long time (where the 319 application decides what "long" means), a receiver MAY close a 320 connection. The receiver MUST attempt to initiate an exchange of 321 closure_notify alerts with the sender/relay before closing the 322 connection. Receivers that are unprepared to receive any more data 323 MAY close the connection after sending the closure_notify alert, thus 324 generating an incomplete close on the sender/relay side. When the 325 sender/relay has received the closure_notify alert from the receiver 326 and still has pending data to send, it SHOULD send the pending data 327 before sending the closure_notify alert. 329 6. Security Consideration 331 6.1. Authentication 333 TLS supports three authentication modes: authentication of both 334 parties, server authentication with an unauthenticated client, and 335 total anonymity. 337 TLS authentication and the establishment of secrets is based on 338 certificates and asymmetric cryptography. This makes TLS transport 339 much more expensive than non-TLS plain transport. An attacker may 340 initialize many TLS connections to a receiver as a denial of service 341 attack. Since a receiver may act upon received data,for syslog over 342 TLS,the receiver SHOULD authenticate the sender/relay to ensure that 343 information received is authentic. 345 When confidentiality is a concern, a sender/relay MUST authenticate 346 the receiver to make sure it is talking to the right peer. 348 6.2. Generic Certificate 350 When a certificate is issued to a class of device or application, the 351 certificate may be shared by multiple hosts. Multiple hosts know the 352 private key of the certificate. When the certificate in one host is 353 compromised, then the certificate for all hosts that share the 354 certificate is compromised. An attacker may impersonate a legitimate 355 sender to send Syslog message to a receiver. 357 7. IANA Consideration 359 7.1. Port Number 361 IANA is requested to assign a TCP port number in the range 1..1023 in 362 the http://www.iana.org/assignments/port-numbers registry which will 363 be the default port for syslog over TLS, as defined in this document. 365 7.2. VERSION 367 IANA must maintain a registry of VERSION values as described in 368 Section 5.3.2. Version numbers MUST be incremented for any new 369 Syslog TLS transport mapping specification that changes any part of 370 the frame or other parts. Changes include addition or removal of 371 fields or a change of syntax or semantics of existing fields. 373 VERSION numbers must be registered via the Standards Action method as 374 described in RFC2434 [5]. IANA must register the VERSIONs shown 375 below. 377 VERSION FORMAT 379 1 According to this specification 381 8. Acknowledgments 383 Authors appreciate Anton Okmianski, Rainer Gerhards, Balazs Scheidler 384 and Chris Lonvick for their effort on issues resolving discussion. 385 Authors would also like to appreciate Balazs Scheidler, Tom Petch and 386 other persons for their input on security threats of Syslog. The 387 author would like to acknowledge David Harrington for his detailed 388 reviews of the content and grammar of the document. 390 9. References 392 9.1. Normative References 394 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 395 Levels", BCP 14, RFC 2119, March 1997. 397 [2] Gerhards, R., "The syslog Protocol", 398 draft-ietf-syslog-protocol-17 (work in progress), June 2006. 400 [3] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 401 Specifications: ABNF", RFC 2234, November 1997. 403 [4] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 404 RFC 2246, January 1999. 406 [5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 407 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 409 [6] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 410 Public Key Infrastructure Certificate and Certificate Revocation 411 List (CRL) Profile", RFC 3280, April 2002. 413 9.2. Informative References 415 [7] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, August 2001. 417 Authors' Addresses 419 Miao Fuyou 420 Huawei Technologies 421 No. 3, Xinxi Rd 422 Shangdi Information Industry Base 423 Haidian District, Beijing 100085 424 P. R. China 426 Phone: +86 10 8288 2008 427 Email: miaofy@huawei.com 428 URI: www.huawei.com 430 Ma Yuzhi 431 Huawei Technologies 432 No. 3, Xinxi Rd 433 Shangdi Information Industry Base 434 Haidian District, Beijing 100085 435 P. R. China 437 Phone: +86 10 8288 2008 438 Email: myz@huawei.com 439 URI: www.huawei.com 441 Full Copyright Statement 443 Copyright (C) The Internet Society (2006). 445 This document is subject to the rights, licenses and restrictions 446 contained in BCP 78, and except as set forth therein, the authors 447 retain all their rights. 449 This document and the information contained herein are provided on an 450 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 451 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 452 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 453 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 454 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 455 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 457 Intellectual Property 459 The IETF takes no position regarding the validity or scope of any 460 Intellectual Property Rights or other rights that might be claimed to 461 pertain to the implementation or use of the technology described in 462 this document or the extent to which any license under such rights 463 might or might not be available; nor does it represent that it has 464 made any independent effort to identify any such rights. Information 465 on the procedures with respect to rights in RFC documents can be 466 found in BCP 78 and BCP 79. 468 Copies of IPR disclosures made to the IETF Secretariat and any 469 assurances of licenses to be made available, or the result of an 470 attempt made to obtain a general license or permission for the use of 471 such proprietary rights by implementers or users of this 472 specification can be obtained from the IETF on-line IPR repository at 473 http://www.ietf.org/ipr. 475 The IETF invites any interested party to bring to its attention any 476 copyrights, patents or patent applications, or other proprietary 477 rights that may cover technology that may be required to implement 478 this standard. Please address the information to the IETF at 479 ietf-ipr@ietf.org. 481 Acknowledgment 483 Funding for the RFC Editor function is provided by the IETF 484 Administrative Support Activity (IASA).