idnits 2.17.1 draft-ietf-syslog-transport-tls-05.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 393. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 404. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 411. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 417. ** 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 (November 28, 2006) is 6358 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) == Unused Reference: '3' is defined on line 342, but no explicit reference was found in the text == Outdated reference: A later version (-23) exists of draft-ietf-syslog-protocol-18 ** 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) Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 7 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: June 1, 2007 November 28, 2006 7 TLS Transport Mapping for Syslog 8 draft-ietf-syslog-transport-tls-05.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 June 1, 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 . . . . . . . . . . . . . . . . . . . . . . 4 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.4. Closure . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 59 5.1. Authentication . . . . . . . . . . . . . . . . . . . . . . 7 60 5.2. Generic Certificate . . . . . . . . . . . . . . . . . . . 7 61 5.3. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 8 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 63 6.1. Port Number . . . . . . . . . . . . . . . . . . . . . . . 8 64 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 65 8. Normative References . . . . . . . . . . . . . . . . . . . . . 8 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 67 Intellectual Property and Copyright Statements . . . . . . . . . . 10 69 1. Introduction 71 This document describes the use of Transport Layer Security (TLS [6]) 72 to provide a secure connection for the transport of Syslog messages. 73 This document describes the security threats to Syslog and how TLS 74 can be used to counter such threats. 76 1.1. Terminology 78 The following definitions are used in this document: 80 o A sender is an application that can generate and send a Syslog [2] 81 message to another application. 83 o A receiver is an application that can receive a Syslog message. 85 o A relay is an application that can receive Syslog messages and 86 forward them to another receiver. 88 o A collector is an application that can receive messages but does 89 not relay them to any other receiver. 91 o A TLS client is an application that can initiate a TLS connection 92 by sending a Client Hello to a peer. 94 o A TLS server is an application that can receive a Client Hello 95 from a peer and reply with a Server Hello. 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in RFC 2119 [1]. 101 2. Security Requirements for Syslog 103 Syslog messages may pass several hops to arrive at the intended 104 receiver. Some intermediary networks may not be trusted by the 105 sender/relay, receiver, or all because the network is in a different 106 security domain or at a different security level from the receiver, 107 relay, or sender. Another security concern is that the sender/relay, 108 or receiver itself is in an insecure network. 110 There are several threats to be addressed for Syslog security. The 111 primary threats are: 113 o Masquerade. An unauthorized sender/relay may send messages to a 114 legitimate receiver, or an unauthorized receiver tries to deceive 115 a legitimate sender/relay into sending Syslog messages to it. 117 o Modification. An attacker between the sender/relay and receiver 118 may modify an in-transit Syslog message from the sender/relay and 119 then forward the message to receiver. Such modification may make 120 the receiver misunderstand the message or cause the receiver to 121 behave in undesirable ways. 123 o Disclosure. An unauthorized entity may examine the content of the 124 Syslog messages, gaining unauthorized access to the information. 125 Some data in Syslog messages is sensitive and may be useful to an 126 attacker, such as the password of an authorized administrator or 127 user. 129 The secondary threat is: 131 o Message stream modification. An attacker may delete a Syslog 132 message from a series of messages, replay a message or alter the 133 delivery sequence. Syslog protocol itself is not based on message 134 order, but an event in a Syslog message may relate semantically to 135 events in other messages, so message ordering may be important to 136 understanding a sequence of events. 138 The following threats are deemed to be of lesser importance for 139 Syslog, and are not addressed in this document: 141 o Denial of Service 143 o Traffic Analysis 145 3. TLS to Secure Syslog 147 TLS can be used as a secure transport to counter all the primary and 148 secondary threats to Syslog described in section 2: 150 o Confidentiality to counter disclosure of the message contents 152 o Integrity check to counter modifications to a message 154 o Peer authentication to counter masquerade 156 o Sequence number along with integrity check to counter message 157 stream modification 159 4. Protocol Elements 160 4.1. Port Assignment 162 A Syslog sender/relay is always a TLS client and a Syslog receiver is 163 always a TLS server. 165 The TCP port NNN has been allocated as the default port for Syslog 166 over TLS, as defined in this document. 168 Note to RFC Editor: please replace NNN with the IANA-assigned value, 169 and remove this note. 171 4.2. Initiation 173 The sender/relay should initiate a connection to the receiver and 174 then send the TLS Client Hello to begin the TLS handshake. When the 175 TLS handshake has finished the sender/relay may then send the first 176 Syslog message. 178 TLS uses certificate [4] to authenticate the peers. When a sender/ 179 relay authenticates a receiver it MUST validate the certificate. It 180 SHOULD check the common name (CN) of the certificate against the host 181 name of the receiver if it has knowledge of a common name/host name 182 mapping. If the common name does not match the host name, the 183 sender/relay SHOULD send an "access_denied" error alert using the TLS 184 alert protocol to terminate the handshake, and then it SHOULD close 185 the connection. 187 When a receiver authenticates a sender/relay, the receiver MUST 188 validate the certificate. A sender's (or relay's) certificate may 189 be: 191 o An unique certificate, which is issued to a host and whose Common 192 Name may be host name, IP address, MAC, or device ID. 194 o A generic certificate, which is issued to a class of application 195 or device. For example, all cable modems from a vendor may be 196 issued the same generic certificate. 198 A sender/relay certificate may be issued by an operator when a 199 device/application is being provisioned or by a vendor when the 200 device/application is manufactured. This document does not define 201 how the sender/relay certificate is issued. 203 Syslog applications SHOULD be implemented in a manner that permits 204 administrators to select the cryptographic level they desire. It 205 SHOULD be an administrator decision, as a matter of local policy, 206 what security level (e.g. cryptographic algorithms and length of 207 keys) is required. 209 TLS permits the resumption of an earlier TLS session or the use of 210 another active session when a new session is requested, in order to 211 save the expense of another full TLS handshake. The security 212 parameters of the resumed session are reused for the requested 213 session. The security parameters SHOULD be checked against security 214 requirement of requested session to make sure the resumed session 215 provides proper security. 217 4.3. Sending data 219 All Syslog messages MUST be sent as TLS "application data". It is 220 possible that there are multiple Syslog messages in one TLS record, 221 or a Syslog message is transferred in multiple TLS records. The 222 application data is defined with the following ABNF [5] expression: 224 APPLICATION-DATA = 1*SYSLOG-FRAME 226 SYSLOG-FRAME = FRAME-LEN SP SYSLOG-MSG 228 FRAME-LEN = NONZERO-DIGIT *DIGIT 230 SP = %d32 232 NONZERO-DIGIT = %d49-57 234 DIGIT = %d48 / NONZERO-DIGIT 236 SYSLOG-MSG is defined in Syslog [2] protocol. 238 4.3.1. Frame Length 240 The frame length is the octet count of a Syslog frame including the 241 FRAME-HEADER and SP parts. A receiver MUST use the frame length 242 field to delimit a Syslog message. There is no upper limit for a 243 frame length per se. However, in order to establish a baseline for 244 interoperability, the specification requires that a receiver MUST be 245 able to process frame with size up to and including 2048 octets. It 246 SHOULD be able to receive frame with size up to and including 8192 247 octets. 249 4.4. Closure 251 A Syslog sender/relay MUST close the associated TLS connection if the 252 connection is not expected to deliver Syslog message later. It MUST 253 send a TLS close_notify alert before closing the connection. A 254 sender/relay MAY choose not to wait for the receiver's close_notify 255 alert and simply close the connection, thus generating an incomplete 256 close on the receiver side. Once the receiver gets close_notify from 257 the sender/relay, it MUST reply with a close_notify unless it becomes 258 aware that the connection has already been closed by the sender/relay 259 (e.g., the closure was indicated by TCP). 261 When no data is received from a connection for a long time (where the 262 application decides what "long" means), a receiver MAY close a 263 connection. The receiver MUST attempt to initiate an exchange of 264 close_notify alerts with the sender/relay before closing the 265 connection. Receivers those are unprepared to receive any more data 266 MAY close the connection after sending the close_notify alert, thus 267 generating an incomplete close on the sender/relay side. When the 268 sender/relay has received the close_notify alert from the receiver 269 and still has pending data to send, it SHOULD send the pending data 270 before sending the close_notify alert. 272 5. Security Considerations 274 5.1. Authentication 276 TLS supports three authentication modes: authentication of both 277 parties, server authentication with an unauthenticated client, and 278 total anonymity. 280 TLS authentication and the establishment of secrets is based on 281 certificates and asymmetric cryptography. This makes TLS transport 282 much more expensive than non-TLS plain transport. An attacker may 283 initialize many TLS connections to a receiver as a denial of service 284 attack. Since a receiver may act upon received data, for Syslog over 285 TLS, the receiver SHOULD authenticate the sender/relay to ensure that 286 information received is authentic. 288 For the deployment where confidentiality is a concern, receiver 289 authentication is required for sender/relay to make sure it is 290 talking to the right peer. It is up to the operator to decide 291 whether confidentiality is a concern for a specific deployment. 293 5.2. Generic Certificate 295 When a certificate is issued to a class of device or application, the 296 certificate may be shared by multiple hosts. Multiple hosts know the 297 private key of the certificate. When the certificate in one host is 298 compromised, then the certificate for all hosts that share the 299 certificate is compromised. An attacker may impersonate a legitimate 300 sender to send Syslog message to a receiver. 302 5.3. Cipher Suites 304 TLS [6]specifies a mandatory cipher suite to enable minimum 305 interoperability for TLS implementation. This specification does not 306 specify a mandatory cipher suite other than the one in TLS 307 specification, and the one for TLS applies to this specification for 308 minimum interoperability purpose. 310 If there is update to TLS specification in the future, the mandatory 311 cipher suite in the update will applies to this specification, too. 312 The implementors and deployers should be aware of the cipher suite 313 mandated in the current TLS specification. 315 6. IANA Considerations 317 6.1. Port Number 319 IANA is requested to assign a TCP port number in the range 1..1023 in 320 the http://www.iana.org/assignments/port-numbers registry which will 321 be the default port for Syslog over TLS, as defined in this document. 323 7. Acknowledgments 325 Authors appreciate Eric Rescorla, Rainer Gerhards, Tom Petch, Anton 326 Okmianski, Balazs Scheidler, Bert Wijnen, and Chris Lonvick for their 327 effort on issues resolving discussion. Authors would also like to 328 appreciate Balazs Scheidler, Tom Petch and other persons for their 330 input on security threats of Syslog. The authors would like to 331 acknowledge David Harrington for his detailed reviews of the content 332 and grammar of the document. 334 8. Normative References 336 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 337 Levels", BCP 14, RFC 2119, March 1997. 339 [2] Gerhards, R., "The syslog Protocol", 340 draft-ietf-syslog-protocol-18 (work in progress), November 2006. 342 [3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 343 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 345 [4] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 346 Public Key Infrastructure Certificate and Certificate Revocation 347 List (CRL) Profile", RFC 3280, April 2002. 349 [5] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 350 Specifications: ABNF", RFC 4234, October 2005. 352 [6] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) 353 Protocol Version 1.1", RFC 4346, April 2006. 355 Authors' Addresses 357 Miao Fuyou 358 Huawei Technologies 359 No. 3, Xinxi Rd 360 Shangdi Information Industry Base 361 Haidian District, Beijing 100085 362 P. R. China 364 Phone: +86 10 8288 2008 365 Email: miaofy@huawei.com 366 URI: www.huawei.com 368 Ma Yuzhi 369 Huawei Technologies 370 No. 3, Xinxi Rd 371 Shangdi Information Industry Base 372 Haidian District, Beijing 100085 373 P. R. China 375 Phone: +86 10 8288 2008 376 Email: myz@huawei.com 377 URI: www.huawei.com 379 Full Copyright Statement 381 Copyright (C) The Internet Society (2006). 383 This document is subject to the rights, licenses and restrictions 384 contained in BCP 78, and except as set forth therein, the authors 385 retain all their rights. 387 This document and the information contained herein are provided on an 388 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 389 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 390 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 391 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 392 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 393 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 395 Intellectual Property 397 The IETF takes no position regarding the validity or scope of any 398 Intellectual Property Rights or other rights that might be claimed to 399 pertain to the implementation or use of the technology described in 400 this document or the extent to which any license under such rights 401 might or might not be available; nor does it represent that it has 402 made any independent effort to identify any such rights. Information 403 on the procedures with respect to rights in RFC documents can be 404 found in BCP 78 and BCP 79. 406 Copies of IPR disclosures made to the IETF Secretariat and any 407 assurances of licenses to be made available, or the result of an 408 attempt made to obtain a general license or permission for the use of 409 such proprietary rights by implementers or users of this 410 specification can be obtained from the IETF on-line IPR repository at 411 http://www.ietf.org/ipr. 413 The IETF invites any interested party to bring to its attention any 414 copyrights, patents or patent applications, or other proprietary 415 rights that may cover technology that may be required to implement 416 this standard. Please address the information to the IETF at 417 ietf-ipr@ietf.org. 419 Acknowledgment 421 Funding for the RFC Editor function is provided by the IETF 422 Administrative Support Activity (IASA).