idnits 2.17.1 draft-ietf-syslog-transport-tls-09.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, updated by RFC 4748 on line 459. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 470. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 477. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 483. 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 Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- 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 (April 23, 2007) is 6213 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-19 ** Obsolete normative reference: RFC 3280 (ref. '3') (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 2818 (ref. '7') (Obsoleted by RFC 9110) Summary: 4 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: October 25, 2007 April 23, 2007 7 TLS Transport Mapping for Syslog 8 draft-ietf-syslog-transport-tls-09.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 October 25, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 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.2.1. Server Identity . . . . . . . . . . . . . . . . . . . 5 56 4.2.2. Client Identity . . . . . . . . . . . . . . . . . . . 6 57 4.2.3. Cryptographic Level . . . . . . . . . . . . . . . . . 7 58 4.3. Sending data . . . . . . . . . . . . . . . . . . . . . . . 7 59 4.3.1. Message Length . . . . . . . . . . . . . . . . . . . . 7 60 4.4. Closure . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 62 5.1. Authentication . . . . . . . . . . . . . . . . . . . . . . 8 63 5.2. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 9 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 65 6.1. Port Number . . . . . . . . . . . . . . . . . . . . . . . 9 66 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 69 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 71 Intellectual Property and Copyright Statements . . . . . . . . . . 11 73 1. Introduction 75 This document describes the use of Transport Layer Security (TLS [6]) 76 to provide a secure connection for the transport of Syslog messages. 77 This document describes the security threats to Syslog and how TLS 78 can be used to counter such threats. 80 1.1. Terminology 82 The following definitions are used in this document: 84 o A sender is an application that can generate and send a Syslog [2] 85 message to another application. 87 o A receiver is an application that can receive a Syslog message. 89 o A relay is an application that can receive Syslog messages and 90 forward them to another receiver. 92 o A collector is an application that can receive messages but does 93 not relay them to any other receiver. 95 o A TLS client is an application that can initiate a TLS connection 96 by sending a Client Hello to a peer. 98 o A TLS server is an application that can receive a Client Hello 99 from a peer and reply with a Server Hello. 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in RFC 2119 [1]. 105 2. Security Requirements for Syslog 107 Syslog messages may pass several hops to arrive at the intended 108 receiver. Some intermediary networks may not be trusted by the 109 sender/relay, receiver, or all because the network is in a different 110 security domain or at a different security level from the receiver, 111 relay, or sender. Another security concern is that the sender/relay, 112 or receiver itself is in an insecure network. 114 There are several threats to be addressed for Syslog security. The 115 primary threats are: 117 o Masquerade. An unauthorized sender/relay may send messages to a 118 legitimate receiver, or an unauthorized receiver tries to deceive 119 a legitimate sender/relay into sending Syslog messages to it. 121 o Modification. An attacker between the sender/relay and receiver 122 may modify an in-transit Syslog message from the sender/relay and 123 then forward the message to receiver. Such modification may make 124 the receiver misunderstand the message or cause the receiver to 125 behave in undesirable ways. 127 o Disclosure. An unauthorized entity may examine the content of the 128 Syslog messages, gaining unauthorized access to the information. 129 Some data in Syslog messages is sensitive and may be useful to an 130 attacker, such as the password of an authorized administrator or 131 user. 133 The secondary threat is: 135 o Message stream modification. An attacker may delete a Syslog 136 message from a series of messages, replay a message or alter the 137 delivery sequence. Syslog protocol itself is not based on message 138 order, but an event in a Syslog message may relate semantically to 139 events in other messages, so message ordering may be important to 140 understanding a sequence of events. 142 The following threats are deemed to be of lesser importance for 143 Syslog, and are not addressed in this document: 145 o Denial of Service 147 o Traffic Analysis 149 3. TLS to Secure Syslog 151 TLS can be used as a secure transport to counter all the primary 152 threats to Syslog described in section 2: 154 o Confidentiality to counter disclosure of the message contents; 156 o Integrity check to counter modifications to a message on a hop-to- 157 hop basis; 159 o Server or mutual authentication to counter masquerade. 161 Note: Secure transport (i.e. TLS) only secures syslog in a hop by 162 hop manner, end to end message stream modificationis threat is not 163 addressed in this document. 165 4. Protocol Elements 167 4.1. Port Assignment 169 A Syslog sender/relay is always a TLS client and a Syslog receiver is 170 always a TLS server. 172 The TCP port NNN has been allocated as the default port for Syslog 173 over TLS, as defined in this document. 175 Note to RFC Editor: please replace NNN with the IANA-assigned value, 176 and remove this note. 178 4.2. Initiation 180 The sender/relay should initiate a connection to the receiver and 181 then send the TLS Client Hello to begin the TLS handshake. When the 182 TLS handshake has finished the sender/relay may then send the first 183 Syslog message. 185 TLS uses certificate [3] to authenticate the peers. If a client 186 authenticates a server it MUST validate the certificate. 187 Authentication in the specification means that it must actually check 188 the certificate other than just exchange the certificate. 190 4.2.1. Server Identity 192 A procedure similar to RFC2818 [7] is used to check the server's 193 identity in the certificate. 195 In general, the client is configured with the hostname or IP address 196 of the TLS server. As a consequence, the hostname or IP address for 197 the server is known to the client. If the hostname (or IP address) 198 is available, the client MUST check it against the server's identity 199 as presented in the server's Certificate message, in order to prevent 200 man-in-the-middle attacks. 202 If the client has external information as to the expected identity of 203 the server, the hostname (or IP address) check MAY be omitted. (For 204 instance, a client may be connecting to a machine whose address and 205 hostname are dynamic but the client knows the certificate that the 206 server will present.) In such cases, it is important to narrow the 207 scope of acceptable certificates as much as possible in order to 208 prevent man in the middle attacks. In special cases, it may be 209 appropriate for the client to simply ignore the server's identity, 210 but it must be understood that this leaves the connection open to 211 active attack. 213 If a subjectAltName extension of type dNSName is present, that MUST 214 be used as the identity. Otherwise, the (most specific) Common Name 215 field in the Subject field of the certificate MUST be used. Although 216 the use of the Common Name is existing practice, it is deprecated and 217 Certification Authorities are encouraged to use the dNSName instead. 219 Matching is performed using the matching rules specified by RFC3280. 220 Names may contain the wildcard character * which is considered to 221 match any single domain name component or component fragment. E.g., 222 *.a.com matches foo.a.com but not bar.foo.a.com. f*.com matches 223 foo.com but not bar.com. If the client is configured with IP address 224 of the server, the hostname should be got first through a trusted 225 mechanism such as a preconfigured hosts table or DNSSEC [8]. 227 In some cases, the iPAddress subjectAltName presents in the 228 certificate, it must exactly match the IP address configured or 229 resolved from configured hostname through a trusted mechanism such as 230 a preconfigured hosts table or DNSSEC. 232 It is recommended to use dNSName in the certificate rather than other 233 type subjectAltName for certification verification, such as 234 ipAddress. If more than one identity of a given type presents in the 235 certificate (e.g., more than one dNSName name), a match in any one of 236 the set is considered acceptable. 238 If the hostname does not match the identity in the certificate, user 239 oriented clients MUST either notify the user (clients MAY give the 240 user the opportunity to continue with the connection in any case) or 241 terminate the connection with a bad certificate error. Automated 242 clients MUST log the error to an appropriate audit log (if available) 243 and SHOULD terminate the connection (with a bad certificate error). 244 Automated clients MAY provide a configuration setting that disables 245 this check, but MUST provide a setting which enables it. 247 4.2.2. Client Identity 249 If a server authenticates a client and the client presents a 250 certificate to the server, the server MUST validate the certificate. 251 The subjectAltName may be host name, IP address, MAC, or device ID 252 etc. SubjectAltName is not necessarily unique for different 253 certificate, for example, certificates for some types of printer 254 might use the same subjectAltName. 256 A client certificate may be issued by an operator when a device/ 257 application is being provisioned or by a vendor when the device/ 258 application is manufactured. This document does not define how the 259 client certificate is issued. 261 4.2.3. Cryptographic Level 263 Syslog applications SHOULD be implemented in a manner that permits 264 administrators, as a matter of local policy, to select the 265 cryptographic level and authentication options they desire. 267 TLS permits the resumption of an earlier TLS session or the use of 268 another active session when a new session is requested, in order to 269 save the expense of another full TLS handshake. The security 270 parameters of the resumed session are reused for the requested 271 session. The security parameters SHOULD be checked against security 272 requirement of requested session to make sure the resumed session 273 provides proper security. 275 4.3. Sending data 277 All Syslog messages MUST be sent as TLS "application data". It is 278 possible that there are multiple Syslog messages in one TLS record, 279 or a Syslog message is transferred in multiple TLS records. The 280 application data is defined with the following ABNF [5] expression: 282 APPLICATION-DATA = 1*SYSLOG-FRAME 284 SYSLOG-FRAME = MSG-LEN SP SYSLOG-MSG 286 MSG-LEN = NONZERO-DIGIT *DIGIT 288 SP = %d32 290 NONZERO-DIGIT = %d49-57 292 DIGIT = %d48 / NONZERO-DIGIT 294 SYSLOG-MSG is defined in Syslog [2] protocol. 296 4.3.1. Message Length 298 The message length is the octet count of the SYSLOG-MSG in the 299 SYSLOG-FRAME. A receiver MUST use the message length to delimit a 300 Syslog message. There is no upper limit for a message length per se. 301 However, in order to establish a baseline for interoperability, the 302 specification requires that a receiver MUST be able to process 303 message with size up to and including 2048 octets. Receiver SHOULD 304 be able to process message with size up to and including 8192 octets. 306 4.4. Closure 308 A TLS client MUST close the associated TLS connection if the 309 connection is not expected to deliver Syslog message later. It MUST 310 send a TLS close_notify alert before closing the connection. A 311 client MAY choose not to wait for the server's close_notify alert and 312 simply close the connection, thus generating an incomplete close on 313 the server side. Once the server gets close_notify from the client, 314 it MUST reply with a close_notify unless it becomes aware that the 315 connection has already been closed by the client (e.g., the closure 316 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 server MAY close a 320 connection. The server MUST attempt to initiate an exchange of 321 close_notify alerts with the client before closing the connection. 322 Servers those are unprepared to receive any more data MAY close the 323 connection after sending the close_notify alert, thus generating an 324 incomplete close on the client side. When the client has received 325 the close_notify alert from the server and still has pending data to 326 send, it SHOULD send the pending data before sending the close_notify 327 alert. 329 5. Security Considerations 331 5.1. Authentication 333 TLS supports three authentication modes: authentication of both 334 parties, server authentication with an unauthenticated client, and 335 total anonymity. An implementation of this specification MUST 336 support all three authentication modes for interoperability. 338 It is RECOMMENDED that mutual authentication should be deployed in 339 all cases as that will prevent masquerade attacks, modification of 340 the messages, and disclosure of the contents of the messages. Server 341 authentication does not prevent masquerade attacks but does prevent 342 modification and disclosure. Unauthenticated TLS sessions does not 343 address any of the threats as an unauthenticated TLS session is 344 susceptible to a man in the middle attack, deploying Syslog over TLS 345 with total anonymity is NOT RECOMMENDED. 347 TLS authentication and the establishment of secrets is based on 348 certificates and asymmetric cryptography. This makes TLS transport 349 more expensive than non-TLS plain transport. An attacker may 350 initialize many TLS connections to a receiver as a denial of service 351 attack. Since a receiver may act upon received data, for Syslog over 352 TLS, it is recommended that the receiver authenticates the sender/ 353 relay to ensure that information received is authentic. 355 5.2. Cipher Suites 357 TLS [6] specifies a mandatory cipher suite to enable minimum 358 interoperability for TLS implementation. This specification does not 359 specify a mandatory cipher suite other than the one in TLS 360 specification, and the one for TLS applies to this specification for 361 minimum interoperability purpose. 363 If there is update to TLS specification in the future, the latest 364 mandatory cipher suite in the update will apply to this 365 specification, too. The implementors and deployers should be aware 366 of the strengths of the public keys algorithm in the suite for 367 exchanging symmetric keys, which is elaborated in BCP86 [4]. The 368 implementors and deployers should also be aware of the latest TLS and 369 other IETF cryptography standards including BCP86. 371 6. IANA Considerations 373 6.1. Port Number 375 IANA is requested to assign a TCP port number in the range 1..1023 in 376 the http://www.iana.org/assignments/port-numbers registry which will 377 be the default port for Syslog over TLS, as defined in this document. 379 7. Acknowledgments 381 Authors appreciate Eric Rescorla, Rainer Gerhards, Tom Petch, Anton 382 Okmianski, Balazs Scheidler, Bert Wijnen, and Chris Lonvick for their 383 effort on issues resolving discussion. Authors would also like to 384 appreciate Balazs Scheidler, Tom Petch and other persons for their 385 input on security threats of Syslog. The authors would like to 386 acknowledge David Harrington for his detailed reviews of the content 387 and grammar of the document. 389 8. References 391 8.1. Normative References 393 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 394 Levels", BCP 14, RFC 2119, March 1997. 396 [2] Gerhards, R., "The syslog Protocol", 397 draft-ietf-syslog-protocol-19 (work in progress), November 2006. 399 [3] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 400 Public Key Infrastructure Certificate and Certificate Revocation 401 List (CRL) Profile", RFC 3280, April 2002. 403 [4] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys 404 Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, 405 April 2004. 407 [5] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 408 Specifications: ABNF", RFC 4234, October 2005. 410 [6] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) 411 Protocol Version 1.1", RFC 4346, April 2006. 413 8.2. Informative References 415 [7] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 417 [8] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 418 "DNS Security Introduction and Requirements", RFC 4033, 419 March 2005. 421 Authors' Addresses 423 Miao Fuyou 424 Huawei Technologies 425 No. 3, Xinxi Rd 426 Shangdi Information Industry Base 427 Haidian District, Beijing 100085 428 P. R. China 430 Phone: +86 10 8288 2008 431 Email: miaofy@huawei.com 432 URI: www.huawei.com 434 Ma Yuzhi 435 Huawei Technologies 436 No. 3, Xinxi Rd 437 Shangdi Information Industry Base 438 Haidian District, Beijing 100085 439 P. R. China 441 Phone: +86 10 8288 2008 442 Email: myz@huawei.com 443 URI: www.huawei.com 445 Full Copyright Statement 447 Copyright (C) The IETF Trust (2007). 449 This document is subject to the rights, licenses and restrictions 450 contained in BCP 78, and except as set forth therein, the authors 451 retain all their rights. 453 This document and the information contained herein are provided on an 454 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 455 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 456 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 457 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 458 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 459 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 461 Intellectual Property 463 The IETF takes no position regarding the validity or scope of any 464 Intellectual Property Rights or other rights that might be claimed to 465 pertain to the implementation or use of the technology described in 466 this document or the extent to which any license under such rights 467 might or might not be available; nor does it represent that it has 468 made any independent effort to identify any such rights. Information 469 on the procedures with respect to rights in RFC documents can be 470 found in BCP 78 and BCP 79. 472 Copies of IPR disclosures made to the IETF Secretariat and any 473 assurances of licenses to be made available, or the result of an 474 attempt made to obtain a general license or permission for the use of 475 such proprietary rights by implementers or users of this 476 specification can be obtained from the IETF on-line IPR repository at 477 http://www.ietf.org/ipr. 479 The IETF invites any interested party to bring to its attention any 480 copyrights, patents or patent applications, or other proprietary 481 rights that may cover technology that may be required to implement 482 this standard. Please address the information to the IETF at 483 ietf-ipr@ietf.org. 485 Acknowledgment 487 Funding for the RFC Editor function is provided by the IETF 488 Administrative Support Activity (IASA).