idnits 2.17.1 draft-ietf-syslog-transport-tls-10.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 468. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 479. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 486. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 492. 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 (May 12, 2007) is 6186 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: November 13, 2007 May 12, 2007 7 TLS Transport Mapping for Syslog 8 draft-ietf-syslog-transport-tls-10.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 November 13, 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 69 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 71 Intellectual Property and Copyright Statements . . . . . . . . . . 12 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 [2] 77 messages. This document describes the security threats to syslog and 78 how TLS can be used to counter such threats. 80 1.1. Terminology 82 The following definitions are used in this document: 84 o A "sender" passes syslog messages to a specific transport 85 protocol. 87 o A "receiver" takes syslog messages from a specific transport 88 protocol. 90 o A "relay" forwards messages, accepting messages from originators 91 or other relays, and sending them to collectors or other relays. 93 o A "collector" gathers syslog content for further analysis. 95 o A "TLS client" is an application that can initiate a TLS 96 connection 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 the 122 receiver may modify an in-transit syslog message from the sender/ 123 relay and then forward the message to the receiver. Such 124 modification may make the receiver misunderstand the message or 125 cause the receiver to behave in undesirable ways. 127 o Disclosure. An unauthorized entity may examine the contents of 128 the syslog messages, gaining unauthorized access to the 129 information. Some data in syslog messages is sensitive and may be 130 useful to an attacker, such as the password of an authorized 131 administrator or user. 133 The secondary threat is: 135 o Message stream modification. An attacker may delete one or more 136 syslog message from a series of messages, replay a message, or 137 alter the delivery sequence. The syslog protocol itself is not 138 based on message order, but an event in a syslog message may 139 relate semantically to events in other messages, so message 140 ordering may be important to 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 checking to counter modifications to a message on a hop- 157 by-hop basis; 159 o Server or mutual authentication to counter masquerade. 161 Note: This secure transport (i.e. TLS) only secures syslog in a hop- 162 by-hop manner, the threat of end-to-end message stream modification 163 is not 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 certificates [3] to authenticate peers. If a client 186 authenticates a server it MUST validate the certificate. 187 Authentication in this specification means that the recipient of a 188 certificate must actually check the certificate rather than just 189 accept a certificate. 191 4.2.1. Server Identity 193 A procedure similar to RFC2818 [7] is used to check the server's 194 identity in the certificate. 196 In general, the client is configured with the hostname or IP address 197 of the TLS server. As a consequence, the hostname or IP address for 198 the server is known to the client. If the hostname (or IP address) 199 is available, the client MUST check it against the server's identity 200 as presented in the server's certificate message, in order to prevent 201 man-in-the-middle attacks. 203 If the client has external information as to the expected identity of 204 the server, the hostname (or IP address) check MAY be omitted. (For 205 instance, a client may be connecting to a machine whose address and 206 hostname are dynamic but the client knows the certificate that the 207 server will present.) In such cases, it is important to narrow the 208 scope of acceptable certificates as much as possible in order to 209 prevent man-in-the-middle attacks. In special cases, it may be 210 appropriate for the client to simply ignore the server's identity, 211 but it must be understood that this leaves the connection open to 212 active attack. 214 If a subjectAltName extension of type dNSName is present, that MUST 215 be used as the identity. Otherwise, the (most specific) Common Name 216 field in the Subject field of the certificate MUST be used. Although 217 the use of the Common Name is current practice, it is deprecated and 218 Certification Authorities are encouraged to use the dNSName instead. 220 Matching is performed using the matching rules specified by RFC3280 221 [3]. Names may contain the wildcard character * which is considered 222 to match any single domain name component or component fragment. 223 E.g., *.a.com matches foo.a.com but not bar.foo.a.com. f*.com matches 224 foo.com but not bar.com. If the client is configured with IP address 225 of the server, the hostname should be got first through a trusted 226 mechanism such as a preconfigured hosts table or DNSSEC [8]. 228 If the iPAddress subjectAltName is present in the certificate, it 229 must exactly match the IP address configured or resolved from the 230 configured hostname through a trusted mechanism such as a 231 preconfigured hosts table or DNSSEC. 233 It is recommended to use dNSName in the certificate rather than any 234 other type subjectAltName for certificate verification, such as 235 ipAddress. If more than one identity of a given type is presented in 236 the certificate (e.g., more than one dNSName name), a match in any 237 one of the set is considered acceptable. 239 If the hostname does not match the identity in the certificate, 240 clients SHOULD log the error in some form or another (see next 241 paragraph), and SHOULD terminate the connection with a bad 242 certificate error. Clients MAY provide a configuration setting that 243 disables this check but MUST enable it by default. 245 The application developer must take some care to consider the case 246 when, for whatever reason, there is a problem with authenticating the 247 other end of the connection. Since this problem will prevent log 248 messages from being transmitted, each device having this problem 249 should use whatever means are available to inform the administrator 250 of the problem. This may include producing an error code on a 251 console, returning an error to a user (if there is one), or writing a 252 file to disk, being mindful that such writes should be rate limited 253 in the case of attacks. 255 4.2.2. Client Identity 257 If a server authenticates a client and the client presents a 258 certificate to the server, the server MUST validate the certificate. 259 The subjectAltName may be the host name, IP address, MAC, device ID, 260 etc. SubjectAltName is not necessarily unique for different 261 certificates. For example, certificates for some types of printer 262 might use the same subjectAltName. 264 A client certificate may be issued by an operator when a device/ 265 application is being provisioned, or by a vendor when the device/ 266 application is manufactured. This document does not define how the 267 client certificate is issued. 269 4.2.3. Cryptographic Level 271 Syslog applications SHOULD be implemented in a manner that permits 272 administrators, as a matter of local policy, to select the 273 cryptographic level and authentication options they desire. 275 TLS permits the resumption of an earlier TLS session or the use of 276 another active session when a new session is requested, in order to 277 save the expense of another full TLS handshake. The security 278 parameters of the resumed session are reused for the requested 279 session. The security parameters SHOULD be checked against the 280 security requirement of the requested session to make sure that the 281 resumed session provides proper security. 283 4.3. Sending data 285 All syslog messages MUST be sent as TLS "application data". It is 286 possible that multiple syslog messages be contained in one TLS 287 record, or that a syslog message be transferred in multiple TLS 288 records. The application data is defined with the following ABNF [5] 289 expression: 291 APPLICATION-DATA = 1*SYSLOG-FRAME 293 SYSLOG-FRAME = MSG-LEN SP SYSLOG-MSG 295 MSG-LEN = NONZERO-DIGIT *DIGIT 297 SP = %d32 299 NONZERO-DIGIT = %d49-57 301 DIGIT = %d48 / NONZERO-DIGIT 303 SYSLOG-MSG is defined in syslog [2] protocol. 305 4.3.1. Message Length 307 The message length is the octet count of the SYSLOG-MSG in the 308 SYSLOG-FRAME. A receiver MUST use the message length to delimit a 309 syslog message. There is no upper limit for a message length per se. 311 However, in order to establish a baseline for interoperability, this 312 specification requires that a receiver MUST be able to process 313 messages with a length up to and including 2048 octets. Receiver 314 SHOULD be able to process messages with lengths up to and including 315 8192 octets. 317 4.4. Closure 319 A TLS client MUST close the associated TLS connection if the 320 connection is not expected to deliver any syslog messages later. It 321 MUST send a TLS close_notify alert before closing the connection. A 322 client MAY choose to not wait for the server's close_notify alert and 323 simply close the connection, thus generating an incomplete close on 324 the server side. Once the server gets a close_notify from the 325 client, it MUST reply with a close_notify unless it becomes aware 326 that the connection has already been closed by the client (e.g., the 327 closure was indicated by TCP). 329 When no data is received from a connection for a long time (where the 330 application decides what "long" means), a server MAY close the 331 connection. The server MUST attempt to initiate an exchange of 332 close_notify alerts with the client before closing the connection. 333 Servers that are unprepared to receive any more data MAY close the 334 connection after sending the close_notify alert, thus generating an 335 incomplete close on the client side. When the client has received 336 the close_notify alert from the server and still has pending data to 337 send, it SHOULD send the pending data before sending the close_notify 338 alert. 340 5. Security Considerations 342 5.1. Authentication 344 TLS supports three authentication modes: authentication of both 345 parties, server authentication with an unauthenticated client, and 346 total anonymity. An implementation compliant with this specification 347 MUST support all three authentication modes for interoperability. 349 It is RECOMMENDED that mutual authentication be deployed in all cases 350 as that will prevent masquerade attacks, modification of the 351 messages, and disclosure of the contents of the messages. Server 352 authentication does not prevent masquerade attacks but does prevent 353 modification and disclosure. Unauthenticated TLS sessions do not 354 address any of the threats as an unauthenticated TLS session is 355 susceptible to a man-in-the-middle attack. Deploying syslog over TLS 356 with total anonymity is NOT RECOMMENDED. 358 TLS authentication and the distribution of keys is based on 359 certificates and asymmetric cryptography. This makes TLS transport 360 more expensive than non-TLS plain transport. An attacker may 361 initialize many TLS connections to a receiver as a denial of service 362 attack. Since a receiver may act upon received data, for syslog over 363 TLS, it is recommended that the receiver authenticate the sender/ 364 relay to ensure that information received is authentic. 366 5.2. Cipher Suites 368 TLS [6] specifies a mandatory cipher suite to enable minimum 369 interoperability for TLS implementation. This specification does not 370 specify any mandatory cipher suite other than the one in the TLS 371 specification, and the cipher suite for TLS applies to this 372 specification for minimum interoperability purposes. 374 If there is an update to the TLS specification in the future, the 375 latest mandatory cipher suite in the update will apply to this 376 specification, too. The implementers and deployers should be aware 377 of the strengths of the public keys algorithm in the suite for 378 exchanging symmetric keys, which is elaborated in BCP86 [4]. The 379 implementers and deployers should also be aware of the latest TLS and 380 other IETF cryptography standards including BCP86. 382 6. IANA Considerations 384 6.1. Port Number 386 IANA is requested to assign a TCP port number in the range 1..1023 in 387 the http://www.iana.org/assignments/port-numbers registry which will 388 be the default port for syslog over TLS, as defined in this document. 390 7. Acknowledgments 392 Authors appreciate Eric Rescorla, Rainer Gerhards, Tom Petch, Anton 393 Okmianski, Balazs Scheidler, Bert Wijnen, and Chris Lonvick for their 394 effort on issues resolving discussion. Authors would also like to 395 appreciate Balazs Scheidler, Tom Petch and other persons for their 396 input on security threats of syslog. The authors would like to 397 acknowledge David Harrington for his detailed reviews of the content 398 and grammar of the document. 400 8. References 401 8.1. Normative References 403 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 404 Levels", BCP 14, RFC 2119, March 1997. 406 [2] Gerhards, R., "The syslog Protocol", 407 draft-ietf-syslog-protocol-19 (work in progress), November 2006. 409 [3] 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 [4] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys 414 Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, 415 April 2004. 417 [5] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 418 Specifications: ABNF", RFC 4234, October 2005. 420 [6] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) 421 Protocol Version 1.1", RFC 4346, April 2006. 423 8.2. Informative References 425 [7] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 427 [8] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 428 "DNS Security Introduction and Requirements", RFC 4033, 429 March 2005. 431 Authors' Addresses 433 Miao Fuyou 434 Huawei Technologies 435 No. 3, Xinxi Rd 436 Shangdi Information Industry Base 437 Haidian District, Beijing 100085 438 P. R. China 440 Phone: +86 10 8288 2008 441 Email: miaofy@huawei.com 442 URI: www.huawei.com 443 Ma Yuzhi 444 Huawei Technologies 445 No. 3, Xinxi Rd 446 Shangdi Information Industry Base 447 Haidian District, Beijing 100085 448 P. R. China 450 Phone: +86 10 8288 2008 451 Email: myz@huawei.com 452 URI: www.huawei.com 454 Full Copyright Statement 456 Copyright (C) The IETF Trust (2007). 458 This document is subject to the rights, licenses and restrictions 459 contained in BCP 78, and except as set forth therein, the authors 460 retain all their rights. 462 This document and the information contained herein are provided on an 463 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 464 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 465 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 466 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 467 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 468 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 470 Intellectual Property 472 The IETF takes no position regarding the validity or scope of any 473 Intellectual Property Rights or other rights that might be claimed to 474 pertain to the implementation or use of the technology described in 475 this document or the extent to which any license under such rights 476 might or might not be available; nor does it represent that it has 477 made any independent effort to identify any such rights. Information 478 on the procedures with respect to rights in RFC documents can be 479 found in BCP 78 and BCP 79. 481 Copies of IPR disclosures made to the IETF Secretariat and any 482 assurances of licenses to be made available, or the result of an 483 attempt made to obtain a general license or permission for the use of 484 such proprietary rights by implementers or users of this 485 specification can be obtained from the IETF on-line IPR repository at 486 http://www.ietf.org/ipr. 488 The IETF invites any interested party to bring to its attention any 489 copyrights, patents or patent applications, or other proprietary 490 rights that may cover technology that may be required to implement 491 this standard. Please address the information to the IETF at 492 ietf-ipr@ietf.org. 494 Acknowledgment 496 Funding for the RFC Editor function is provided by the IETF 497 Administrative Support Activity (IASA).