idnits 2.17.1 draft-ietf-syslog-transport-tls-07.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 458. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 469. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 476. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 482. 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 (March 29, 2007) is 6237 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: September 30, 2007 March 29, 2007 7 TLS Transport Mapping for Syslog 8 draft-ietf-syslog-transport-tls-07.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 September 30, 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 (or IP address) does not match the identity in the 239 certificate, the clients MUST terminate the connection with a bad 240 certificate error. Clients MAY log the error to an appropriate audit 241 log (if available) and SHOULD terminate the connection (with a bad 242 certificate error). 244 4.2.2. Client Identity 246 If a server authenticates a client and the client presents a 247 certificate to the server, the server MUST validate the certificate. 248 A client's certificate must be associated with a unique private key . 249 Private keys MUST NOT be shared between clients. The subjectAltName 250 may be host name, IP address, MAC, or device ID etc. SubjectAltName 251 is not necessarily unique for different certificate, for example, 252 certificates for some type printer shares same type code as 253 subjectAltName. 255 A client certificate may be issued by an operator when a device/ 256 application is being provisioned or by a vendor when the device/ 257 application is manufactured. This document does not define how the 258 client certificate is issued. 260 4.2.3. Cryptographic Level 262 Syslog applications MUST be implemented in a manner that permits 263 administrators, as a matter of local policy, to select the 264 cryptographic level and authentication options they desire. 266 TLS permits the resumption of an earlier TLS session or the use of 267 another active session when a new session is requested, in order to 268 save the expense of another full TLS handshake. The security 269 parameters of the resumed session are reused for the requested 270 session. The security parameters SHOULD be checked against security 271 requirement of requested session to make sure the resumed session 272 provides proper security. 274 4.3. Sending data 276 All Syslog messages MUST be sent as TLS "application data". It is 277 possible that there are multiple Syslog messages in one TLS record, 278 or a Syslog message is transferred in multiple TLS records. The 279 application data is defined with the following ABNF [5] expression: 281 APPLICATION-DATA = 1*SYSLOG-FRAME 283 SYSLOG-FRAME = MSG-LEN SP SYSLOG-MSG 285 MSG-LEN = NONZERO-DIGIT *DIGIT 287 SP = %d32 289 NONZERO-DIGIT = %d49-57 291 DIGIT = %d48 / NONZERO-DIGIT 293 SYSLOG-MSG is defined in Syslog [2] protocol. 295 4.3.1. Message Length 297 The message length is the octet count of the SYSLOG-MSG in the 298 SYSLOG-FRAME. A receiver MUST use the message length to delimit a 299 Syslog message. There is no upper limit for a message length per se. 300 However, in order to establish a baseline for interoperability, the 301 specification requires that a receiver MUST be able to process 302 message with size up to and including 2048 octets. Receiver SHOULD 303 be able to process message with size up to and including 8192 octets. 305 4.4. Closure 307 A TLS client MUST close the associated TLS connection if the 308 connection is not expected to deliver Syslog message later. It MUST 309 send a TLS close_notify alert before closing the connection. A 310 client MAY choose not to wait for the server's close_notify alert and 311 simply close the connection, thus generating an incomplete close on 312 the server side. Once the server gets close_notify from the client, 313 it MUST reply with a close_notify unless it becomes aware that the 314 connection has already been closed by the client (e.g., the closure 315 was indicated by TCP). 317 When no data is received from a connection for a long time (where the 318 application decides what "long" means), a server MAY close a 319 connection. The server MUST attempt to initiate an exchange of 320 close_notify alerts with the client before closing the connection. 321 Servers those are unprepared to receive any more data MAY close the 322 connection after sending the close_notify alert, thus generating an 323 incomplete close on the client side. When the client has received 324 the close_notify alert from the server and still has pending data to 325 send, it SHOULD send the pending data before sending the close_notify 326 alert. 328 5. Security Considerations 330 5.1. Authentication 332 TLS supports three authentication modes: authentication of both 333 parties, server authentication with an unauthenticated client, and 334 total anonymity. An implementation of this specification MUST 335 support all three authentication modes for interoperability. 337 It is RECOMMENDED that mutual authentication should be deployed in 338 all cases as that will prevent masquerade attacks, modification of 339 the messages, and disclosure of the contents of the messages. Server 340 authentication does not prevent masquerade attacks but does prevent 341 modification and disclosure. Unauthenticated TLS sessions does not 342 address any of the threats as an unauthenticated TLS session is 343 susceptible to a man in the middle attack, deploying Syslog over TLS 344 with total anonymity is NOT RECOMMENDED. 346 TLS authentication and the establishment of secrets is based on 347 certificates and asymmetric cryptography. This makes TLS transport 348 more expensive than non-TLS plain transport. An attacker may 349 initialize many TLS connections to a receiver as a denial of service 350 attack. Since a receiver may act upon received data, for Syslog over 351 TLS, it is recommended that the receiver authenticates the sender/ 352 relay to ensure that information received is authentic. 354 5.2. Cipher Suites 356 TLS [6] specifies a mandatory cipher suite to enable minimum 357 interoperability for TLS implementation. This specification does not 358 specify a mandatory cipher suite other than the one in TLS 359 specification, and the one for TLS applies to this specification for 360 minimum interoperability purpose. 362 If there is update to TLS specification in the future, the latest 363 mandatory cipher suite in the update will apply to this 364 specification, too. The implementors and deployers should be aware 365 of the strengths of the public keys algorithm in the suite for 366 exchanging symmetric keys, which is elaborated in BCP86 [4]. The 367 implementors and deployers should also be aware of the latest TLS and 368 other IETF cryptography standards including BCP86. 370 6. IANA Considerations 372 6.1. Port Number 374 IANA is requested to assign a TCP port number in the range 1..1023 in 375 the http://www.iana.org/assignments/port-numbers registry which will 376 be the default port for Syslog over TLS, as defined in this document. 378 7. Acknowledgments 380 Authors appreciate Eric Rescorla, Rainer Gerhards, Tom Petch, Anton 381 Okmianski, Balazs Scheidler, Bert Wijnen, and Chris Lonvick for their 382 effort on issues resolving discussion. Authors would also like to 383 appreciate Balazs Scheidler, Tom Petch and other persons for their 384 input on security threats of Syslog. The authors would like to 385 acknowledge David Harrington for his detailed reviews of the content 386 and grammar of the document. 388 8. References 390 8.1. Normative References 392 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 393 Levels", BCP 14, RFC 2119, March 1997. 395 [2] Gerhards, R., "The syslog Protocol", 396 draft-ietf-syslog-protocol-19 (work in progress), November 2006. 398 [3] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 399 Public Key Infrastructure Certificate and Certificate Revocation 400 List (CRL) Profile", RFC 3280, April 2002. 402 [4] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys 403 Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, 404 April 2004. 406 [5] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 407 Specifications: ABNF", RFC 4234, October 2005. 409 [6] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) 410 Protocol Version 1.1", RFC 4346, April 2006. 412 8.2. Informative References 414 [7] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 416 [8] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 417 "DNS Security Introduction and Requirements", RFC 4033, 418 March 2005. 420 Authors' Addresses 422 Miao Fuyou 423 Huawei Technologies 424 No. 3, Xinxi Rd 425 Shangdi Information Industry Base 426 Haidian District, Beijing 100085 427 P. R. China 429 Phone: +86 10 8288 2008 430 Email: miaofy@huawei.com 431 URI: www.huawei.com 433 Ma Yuzhi 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: myz@huawei.com 442 URI: www.huawei.com 444 Full Copyright Statement 446 Copyright (C) The IETF Trust (2007). 448 This document is subject to the rights, licenses and restrictions 449 contained in BCP 78, and except as set forth therein, the authors 450 retain all their rights. 452 This document and the information contained herein are provided on an 453 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 454 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 455 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 456 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 457 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 458 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 460 Intellectual Property 462 The IETF takes no position regarding the validity or scope of any 463 Intellectual Property Rights or other rights that might be claimed to 464 pertain to the implementation or use of the technology described in 465 this document or the extent to which any license under such rights 466 might or might not be available; nor does it represent that it has 467 made any independent effort to identify any such rights. Information 468 on the procedures with respect to rights in RFC documents can be 469 found in BCP 78 and BCP 79. 471 Copies of IPR disclosures made to the IETF Secretariat and any 472 assurances of licenses to be made available, or the result of an 473 attempt made to obtain a general license or permission for the use of 474 such proprietary rights by implementers or users of this 475 specification can be obtained from the IETF on-line IPR repository at 476 http://www.ietf.org/ipr. 478 The IETF invites any interested party to bring to its attention any 479 copyrights, patents or patent applications, or other proprietary 480 rights that may cover technology that may be required to implement 481 this standard. Please address the information to the IETF at 482 ietf-ipr@ietf.org. 484 Acknowledgment 486 Funding for the RFC Editor function is provided by the IETF 487 Administrative Support Activity (IASA).