idnits 2.17.1 draft-ietf-syslog-transport-tls-11.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 499. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 510. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 517. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 523. 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 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 17, 2007) is 6005 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) ** 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 (~~), 1 warning (==), 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 Y. Ma 4 Intended status: Standards Track Huawei Technologies 5 Expires: May 20, 2008 November 17, 2007 7 TLS Transport Mapping for Syslog 8 draft-ietf-syslog-transport-tls-11.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 May 20, 2008. 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 . . . . . . . . . . . . . . . . . . . 7 57 4.2.3. Cryptographic Level . . . . . . . . . . . . . . . . . 7 58 4.3. Sending data . . . . . . . . . . . . . . . . . . . . . . . 7 59 4.3.1. Message Length . . . . . . . . . . . . . . . . . . . . 8 60 4.4. Closure . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 62 5.1. Authentication and Certificates . . . . . . . . . . . . . 8 63 5.2. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 9 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 65 6.1. Port Number . . . . . . . . . . . . . . . . . . . . . . . 10 66 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 69 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 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 An "originator" generates syslog content to be carried in a 85 message. 87 o A "collector" gathers syslog content for further analysis. 89 o A "relay" forwards messages, accepting messages from originators 90 or other relays, and sending them to collectors or other relays. 92 o A "transport sender" passes syslog messages to a specific 93 transport protocol. 95 o A "transport receiver" takes syslog messages from a specific 96 transport protocol. 98 o A "TLS client" is an application that can initiate a TLS 99 connection by sending a Client Hello to a peer. 101 o A "TLS server" is an application that can receive a Client Hello 102 from a peer and reply with a Server Hello. 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in RFC 2119 [1]. 108 2. Security Requirements for Syslog 110 syslog messages may pass several hops to arrive at the intended 111 collector. Some intermediary networks may not be trusted by the 112 originator, relay, receiver, or all because the network is in a 113 different security domain or at a different security level from the 114 originator, relay, or collector. Another security concern is that 115 the originator, relay, or receiver itself is in an insecure network. 117 There are several threats to be addressed for syslog security. The 118 primary threats are: 120 o Masquerade. An unauthorized transport sender may send messages to 121 a legitimate transport receiver, or an unauthorized transport 122 receiver tries to deceive a legitimate transport sender into 123 sending syslog messages to it. 125 o Modification. An attacker between the transport sender and the 126 transport receiver may modify an in-transit syslog message and 127 then forward the message to the transport receiver. Such 128 modification may make the transport receiver misunderstand the 129 message or cause it to behave in undesirable ways. 131 o Disclosure. An unauthorized entity may examine the contents of 132 the syslog messages, gaining unauthorized access to the 133 information. Some data in syslog messages is sensitive and may be 134 useful to an attacker, such as the password of an authorized 135 administrator or user. 137 The secondary threat is: 139 o Message stream modification. An attacker may delete one or more 140 syslog message from a series of messages, replay a message, or 141 alter the delivery sequence. The syslog protocol itself is not 142 based on message order, but an event in a syslog message may 143 relate semantically to events in other messages, so message 144 ordering may be important to understanding a sequence of events. 146 The following threats are deemed to be of lesser importance for 147 syslog, and are not addressed in this document: 149 o Denial of Service 151 o Traffic Analysis 153 3. TLS to Secure Syslog 155 TLS can be used as a secure transport to counter all the primary 156 threats to syslog described in section 2: 158 o Confidentiality to counter disclosure of the message contents; 160 o Integrity checking to counter modifications to a message on a hop- 161 by-hop basis; 163 o Server or mutual authentication to counter masquerade. 165 Note: This secure transport (i.e. TLS) only secures syslog in a hop- 166 by-hop manner, the threat of end-to-end message stream modification 167 is not addressed in this document. 169 4. Protocol Elements 171 4.1. Port Assignment 173 A syslog transport sender is always a TLS client and a transport 174 receiver is always a TLS server. 176 The TCP port NNN has been allocated as the default port for syslog 177 over TLS, as defined in this document. 179 Note to RFC Editor: please replace NNN with the IANA-assigned value, 180 and remove this note. 182 4.2. Initiation 184 The transport sender should initiate a connection to the transport 185 receiver and then send the TLS Client Hello to begin the TLS 186 handshake. When the TLS handshake has finished the transport sender 187 MAY then send the first syslog message. 189 TLS uses certificates [3] to authenticate peers. Authentication in 190 this specification means that the recipient of a certificate must 191 actually validate the certificate rather than just accept a 192 certificate. Validation includes constructing a certificate path to 193 one of the configured trust anchors and validating that path, and the 194 identity check against the rules defined in section 4.2.1 and section 195 4.2.2. 197 4.2.1. Server Identity 199 A procedure similar to RFC2818 [7] is used to check the server's 200 identity in the certificate. 202 In general, the client is configured with the hostname or IP address 203 of the TLS server. As a consequence, the hostname or IP address for 204 the server is known to the client. If the hostname (or IP address) 205 is available, the client MUST check it against the server's identity 206 as presented in the server's certificate message, in order to prevent 207 man-in-the-middle attacks. 209 If the client has external information as to the expected identity of 210 the server, the hostname (or IP address) check MAY be omitted. (For 211 instance, a client may be connecting to a machine whose address and 212 hostname are dynamic but the client knows the certificate that the 213 server will present.) In such cases, it is important to narrow the 214 scope of acceptable certificates as much as possible in order to 215 prevent man-in-the-middle attacks. In special cases, it may be 216 appropriate for the client to simply ignore the server's identity, 217 but it must be understood that this leaves the connection open to 218 active attack. 220 If a subjectAltName extension of type dNSName is present, that MUST 221 be used as the identity. Otherwise, the (most specific) Common Name 222 field in the Subject field of the certificate MUST be used. Although 223 the use of the Common Name is current practice, it is deprecated and 224 Certification Authorities are encouraged to use the dNSName instead. 226 Matching is performed using the matching rules specified by RFC3280 227 [3]. Names may contain the wildcard character * which is considered 228 to match any single domain name component or component fragment. 229 E.g., *.a.com matches foo.a.com but not bar.foo.a.com. f*.com matches 230 foo.com but not bar.com. If the client is configured with IP address 231 of the server, the hostname should be got first through a trusted 232 mechanism such as a preconfigured hosts table or DNSSEC [8]. 234 If the iPAddress subjectAltName is present in the certificate, it 235 must exactly match the IP address configured or resolved from the 236 configured hostname through a trusted mechanism such as a 237 preconfigured hosts table or DNSSEC. 239 It is recommended to use dNSName in the certificate rather than any 240 other type subjectAltName for certificate verification, such as 241 ipAddress. If more than one identity of a given type is presented in 242 the certificate (e.g., more than one dNSName name), a match in any 243 one of the set is considered acceptable. 245 If the hostname does not match the identity in the certificate, 246 clients SHOULD log the error in some form or another (see next 247 paragraph), and SHOULD terminate the connection with a bad 248 certificate error. Clients MAY provide a configuration setting that 249 disables this check but MUST enable it by default. 251 The application developer must take some care to consider the case 252 when, for whatever reason, there is a problem with authenticating the 253 other end of the connection. Since this problem will prevent log 254 messages from being transmitted, each device having this problem 255 should use whatever means are available to inform the administrator 256 of the problem. This may include producing an error code on a 257 console, returning an error to a user (if there is one), or writing a 258 file to disk, being mindful that such writes should be rate limited 259 in the case of attacks. 261 4.2.2. Client Identity 263 If a server authenticates a client and the client presents a 264 certificate to the server, the server MUST validate the certificate. 265 Validation includes constructing a certificate path to one of the 266 configured trust anchors and validating that path. However, identity 267 check is not required even if subjectAltName is presented in the 268 certificate. 270 The subjectAltName may be the host name, IP address, MAC, device ID, 271 etc. SubjectAltName is not necessarily unique for different 272 certificates. For example, certificates for some types of printer 273 might use the same subjectAltName. 275 A client certificate may be issued by an operator when a device/ 276 application is being provisioned, or by a vendor when the device/ 277 application is manufactured. This document does not define how the 278 client certificate is issued. 280 4.2.3. Cryptographic Level 282 Syslog applications SHOULD be implemented in a manner that permits 283 administrators, as a matter of local policy, to select the 284 cryptographic level and authentication options they desire. 286 TLS permits the resumption of an earlier TLS session or the use of 287 another active session when a new session is requested, in order to 288 save the expense of another full TLS handshake. The security 289 parameters of the resumed session are reused for the requested 290 session. The security parameters SHOULD be checked against the 291 security requirement of the requested session to make sure that the 292 resumed session provides proper security. 294 4.3. Sending data 296 All syslog messages MUST be sent as TLS "application data". It is 297 possible that multiple syslog messages be contained in one TLS 298 record, or that a syslog message be transferred in multiple TLS 299 records. The application data is defined with the following ABNF [5] 300 expression: 302 APPLICATION-DATA = 1*SYSLOG-FRAME 304 SYSLOG-FRAME = MSG-LEN SP SYSLOG-MSG 306 MSG-LEN = NONZERO-DIGIT *DIGIT 308 SP = %d32 309 NONZERO-DIGIT = %d49-57 311 DIGIT = %d48 / NONZERO-DIGIT 313 SYSLOG-MSG is defined in syslog [2] protocol. 315 4.3.1. Message Length 317 The message length is the octet count of the SYSLOG-MSG in the 318 SYSLOG-FRAME. A tranport receiver MUST use the message length to 319 delimit a syslog message. There is no upper limit for a message 320 length per se. However, in order to establish a baseline for 321 interoperability, this specification requires that a transport 322 receiver MUST be able to process messages with a length up to and 323 including 2048 octets. Transport receiver SHOULD be able to process 324 messages with lengths up to and including 8192 octets. 326 4.4. Closure 328 A TLS client MUST close the associated TLS connection if the 329 connection is not expected to deliver any syslog messages later. It 330 MUST send a TLS close_notify alert before closing the connection. A 331 client MAY choose to not wait for the server's close_notify alert and 332 simply close the connection, thus generating an incomplete close on 333 the server side. Once the server gets a close_notify from the 334 client, it MUST reply with a close_notify unless it becomes aware 335 that the connection has already been closed by the client (e.g., the 336 closure was indicated by TCP). 338 When no data is received from a connection for a long time (where the 339 application decides what "long" means), a server MAY close the 340 connection. The server MUST attempt to initiate an exchange of 341 close_notify alerts with the client before closing the connection. 342 Servers that are unprepared to receive any more data MAY close the 343 connection after sending the close_notify alert, thus generating an 344 incomplete close on the client side. When the client has received 345 the close_notify alert from the server and still has pending data to 346 send, it SHOULD send the pending data before sending the close_notify 347 alert. 349 5. Security Considerations 351 5.1. Authentication and Certificates 353 In security sensitive environments, it is recommended that mutual 354 authentication be deployed as that will prevent masquerade attacks, 355 modification of the messages, and disclosure of the contents of the 356 messages. Mutual authentication means the TLS client and server are 357 provisioned with necessary trust roots and must perform certificate 358 validation. 360 In security insensitive environments, the client or server may forego 361 certificate validation. Note that this opens up the protocol for an 362 active man-in-the middle attack if none of the parties are 363 authenticated against trust anchors. It is recommended that server 364 is configured with certificate, and the client validates the 365 certificate against provisioned trust anchors. If a server does not 366 have a certificate and key/pair configured then it must generate a 367 key pair and a self-signed certificate to make the protocol work. If 368 the syslog client does not have a certificate then it may generate a 369 self signed certificate. 371 The server MUST be implemented to support certificate and certificate 372 generation, and certificate validation MUST be implemented for all 373 clients. The Syslog client SHOULD be implementated to support 374 certificate and certificate generation, and certificate validation 375 SHOULD be inplemented for Syslog server. In order to provide better 376 protection for future session the client and server MAY cache the 377 certificate presented by its peer so it can compare the certificate 378 with what is presented in subsequent connections. Note that 379 generated certificates should be persistent in this case. 381 TLS authentication and the distribution of keys is based on 382 certificates and asymmetric cryptography. This makes TLS transport 383 more expensive than non-TLS plain transport. An attacker may 384 initialize many TLS connections to a receiver as a denial of service 385 attack. Since a receiver may act upon received data, for syslog over 386 TLS, it is recommended that the server authenticate the client to 387 ensure that information received is authentic. 389 5.2. Cipher Suites 391 This specification specifies the following cipher suite required for 392 all compliant implementation for minimum interoperability purposes: 394 TLS_RSA_WITH_AES_128_CBC_SHA 396 Operators MAY choose to disable older/weaker cipher suites for TLS 397 despite the tradeoff of interoperability, for example, if the cipher 398 suite specified in the specification is found weak in the future. 399 This allows the future update of the specification to change 400 mandatory-to-implement cipher requirement for interoperability. This 401 also allows the TLS community to change its recommendations, and 402 operators to follow those recommendations. 404 The implementers and deployers should be aware of the strengths of 405 the public keys algorithm in the suite for exchanging symmetric keys, 406 which is elaborated in BCP86 [4]. The implementers and deployers 407 should also be aware of the latest TLS and other IETF cryptography 408 standards including BCP86. 410 6. IANA Considerations 412 6.1. Port Number 414 IANA is requested to assign a TCP port number in the range 1..1023 in 415 the http://www.iana.org/assignments/port-numbers registry which will 416 be the default port for syslog over TLS, as defined in this document. 418 7. Acknowledgments 420 Authors appreciate Eric Rescorla, Rainer Gerhards, Tom Petch, Anton 421 Okmianski, Balazs Scheidler, Bert Wijnen, and Chris Lonvick for their 422 effort on issues resolving discussion. Authors would also like to 423 appreciate Balazs Scheidler, Tom Petch and other persons for their 424 input on security threats of syslog. The authors would like to 425 acknowledge David Harrington for his detailed reviews of the content 426 and grammar of the document. 428 8. References 430 8.1. Normative References 432 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 433 Levels", BCP 14, RFC 2119, March 1997. 435 [2] Gerhards, R., "The syslog Protocol", 436 draft-ietf-syslog-protocol-23 (work in progress), 437 September 2007. 439 [3] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 440 Public Key Infrastructure Certificate and Certificate Revocation 441 List (CRL) Profile", RFC 3280, April 2002. 443 [4] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys 444 Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, 445 April 2004. 447 [5] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 448 Specifications: ABNF", RFC 4234, October 2005. 450 [6] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) 451 Protocol Version 1.1", RFC 4346, April 2006. 453 8.2. Informative References 455 [7] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 457 [8] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 458 "DNS Security Introduction and Requirements", RFC 4033, 459 March 2005. 461 Authors' Addresses 463 Fuyou Miao 464 Huawei Technologies 465 No. 3, Xinxi Rd 466 Shangdi Information Industry Base 467 Haidian District, Beijing 100085 468 P. R. China 470 Phone: +86 10 8288 2008 471 Email: miaofy@huawei.com 472 URI: www.huawei.com 474 Yuzhi Ma 475 Huawei Technologies 476 No. 3, Xinxi Rd 477 Shangdi Information Industry Base 478 Haidian District, Beijing 100085 479 P. R. China 481 Phone: +86 10 8288 2008 482 Email: myz@huawei.com 483 URI: www.huawei.com 485 Full Copyright Statement 487 Copyright (C) The IETF Trust (2007). 489 This document is subject to the rights, licenses and restrictions 490 contained in BCP 78, and except as set forth therein, the authors 491 retain all their rights. 493 This document and the information contained herein are provided on an 494 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 495 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 496 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 497 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 498 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 499 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 501 Intellectual Property 503 The IETF takes no position regarding the validity or scope of any 504 Intellectual Property Rights or other rights that might be claimed to 505 pertain to the implementation or use of the technology described in 506 this document or the extent to which any license under such rights 507 might or might not be available; nor does it represent that it has 508 made any independent effort to identify any such rights. Information 509 on the procedures with respect to rights in RFC documents can be 510 found in BCP 78 and BCP 79. 512 Copies of IPR disclosures made to the IETF Secretariat and any 513 assurances of licenses to be made available, or the result of an 514 attempt made to obtain a general license or permission for the use of 515 such proprietary rights by implementers or users of this 516 specification can be obtained from the IETF on-line IPR repository at 517 http://www.ietf.org/ipr. 519 The IETF invites any interested party to bring to its attention any 520 copyrights, patents or patent applications, or other proprietary 521 rights that may cover technology that may be required to implement 522 this standard. Please address the information to the IETF at 523 ietf-ipr@ietf.org. 525 Acknowledgment 527 Funding for the RFC Editor function is provided by the IETF 528 Administrative Support Activity (IASA).