idnits 2.17.1 draft-ietf-syslog-transport-tls-12.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 548. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 559. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 566. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 572. 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 (May 7, 2008) is 5831 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Syslog Working Group F. Miao, Ed. 3 Internet-Draft Y. Ma, Ed. 4 Intended status: Standards Track Huawei Technologies 5 Expires: November 8, 2008 J. Salowey, Ed. 6 Cisco Systems, Inc. 7 May 7, 2008 9 TLS Transport Mapping for Syslog 10 draft-ietf-syslog-transport-tls-12.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on November 8, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2008). 41 Abstract 43 This document describes the use of Transport Layer Security (TLS) to 44 provide a secure connection for the transport of syslog messages. 45 This document describes the security threats to syslog and how TLS 46 can be used to counter such threats. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Security Requirements for Syslog . . . . . . . . . . . . . . . 3 53 3. TLS to Secure Syslog . . . . . . . . . . . . . . . . . . . . . 4 54 4. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 5 55 4.1. Port Assignment . . . . . . . . . . . . . . . . . . . . . 5 56 4.2. Initiation . . . . . . . . . . . . . . . . . . . . . . . . 5 57 4.2.1. Server Authentication and Basic Authorization . . . . 5 58 4.2.2. Client Authentication and Authorization . . . . . . . 7 59 4.2.3. Certificate Fingerprints . . . . . . . . . . . . . . . 7 60 4.2.4. Cryptographic Level . . . . . . . . . . . . . . . . . 8 61 4.3. Sending data . . . . . . . . . . . . . . . . . . . . . . . 8 62 4.3.1. Message Length . . . . . . . . . . . . . . . . . . . . 8 63 4.4. Closure . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 65 5.1. Authentication and Certificates . . . . . . . . . . . . . 9 66 5.2. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 10 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 68 6.1. Port Number . . . . . . . . . . . . . . . . . . . . . . . 11 69 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 72 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 74 Intellectual Property and Copyright Statements . . . . . . . . . . 13 76 1. Introduction 78 This document describes the use of Transport Layer Security (TLS [5]) 79 to provide a secure connection for the transport of syslog [2] 80 messages. This document describes the security threats to syslog and 81 how TLS can be used to counter such threats. 83 1.1. Terminology 85 The following definitions are used in this document: 87 o An "originator" generates syslog content to be carried in a 88 message. 90 o A "collector" gathers syslog content for further analysis. 92 o A "relay" forwards messages, accepting messages from originators 93 or other relays, and sending them to collectors or other relays. 95 o A "transport sender" passes syslog messages to a specific 96 transport protocol. 98 o A "transport receiver" takes syslog messages from a specific 99 transport protocol. 101 o A "TLS client" is an application that can initiate a TLS 102 connection by sending a Client Hello to a peer. 104 o A "TLS server" is an application that can receive a Client Hello 105 from a peer and reply with a Server Hello. 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in RFC 2119 [1]. 111 2. Security Requirements for Syslog 113 syslog messages may transit several hops to arrive at the intended 114 collector. Some intermediary networks may not be trusted by the 115 originator, relay, or receiver because the network is in a different 116 security domain or at a different security level from the originator, 117 relay, or collector. Another security concern is that the 118 originator, relay, or receiver itself is in an insecure network. 120 There are several threats to be addressed for syslog security. The 121 primary threats are: 123 o Masquerade. An unauthorized transport sender may send messages to 124 a legitimate transport receiver, or an unauthorized transport 125 receiver tries to deceive a legitimate transport sender into 126 sending syslog messages to it. 128 o Modification. An attacker between the transport sender and the 129 transport receiver may modify an in-transit syslog message and 130 then forward the message to the transport receiver. Such 131 modification may make the transport receiver misunderstand the 132 message or cause it to behave in undesirable ways. 134 o Disclosure. An unauthorized entity may examine the contents of 135 the syslog messages, gaining unauthorized access to the 136 information. Some data in syslog messages is sensitive and may be 137 useful to an attacker, such as the password of an authorized 138 administrator or user. 140 The secondary threat is: 142 o Message stream modification. An attacker may delete one or more 143 syslog message from a series of messages, replay a message, or 144 alter the delivery sequence. The syslog protocol itself is not 145 based on message order, but an event in a syslog message may 146 relate semantically to events in other messages, so message 147 ordering may be important to understanding a sequence of events. 149 The following threats are deemed to be of lesser importance for 150 syslog, and are not addressed in this document: 152 o Denial of Service 154 o Traffic Analysis 156 3. TLS to Secure Syslog 158 TLS can be used as a secure transport to counter all the primary 159 threats to syslog described in section 2: 161 o Confidentiality to counter disclosure of the message contents; 163 o Integrity checking to counter modifications to a message on a hop- 164 by-hop basis; 166 o Server or mutual authentication to counter masquerade. 168 Note: This secure transport (i.e. TLS) only secures syslog in a hop- 169 by-hop manner, the threat of end-to-end message stream modification 170 is not addressed in this document. 172 4. Protocol Elements 174 4.1. Port Assignment 176 A syslog transport sender is always a TLS client and a transport 177 receiver is always a TLS server. 179 The TCP port NNN has been allocated as the default port for syslog 180 over TLS, as defined in this document. 182 Note to RFC Editor: please replace NNN with the IANA-assigned value, 183 and remove this note. 185 4.2. Initiation 187 The transport sender should initiate a connection to the transport 188 receiver and then send the TLS Client Hello to begin the TLS 189 handshake. When the TLS handshake has finished the transport sender 190 MAY then send the first syslog message. 192 TLS typically uses certificates [3] to authenticate peers. 193 Authentication and authorization of the TLS server (transport 194 receiver) is described in Section 4.2.1; authentication and 195 authorization of the TLS client (transport sender) is described in 196 Section 4.2.2. 198 4.2.1. Server Authentication and Basic Authorization 200 [Editor's Note: Text referencing RFC2818 was removed, it is not clear 201 that it is all the relevant to SYSLOG.] 203 [Editor's Note: Option for certificate fingerprint added] 205 The transport sender (TLS client) has three different options for 206 authenticating and authorizing the transport receiver (TLS server). 208 o Certification path validation and subject name verification: the 209 client is configured with one or more trust anchors, and for each 210 transport receiver, the name to be matched against the certificate 211 for authorization. This option MUST be supported. 213 o Certificate fingerprints: For each transport receiver, the client 214 is configured with a fingerprint of the server's certificate 215 (which can be self-signed). This option MUST be supported. 217 o No server authentication/authorization: The client is configured 218 to accept any certificate from the server. This option MAY be 219 supported, but MUST NOT be enabled by default. 221 For certification path validation, client implementations MUST 222 provide a mechanism for configuring one or more trust anchors, and 223 MUST perform certification path validation as specified in [3]. 225 For subject name verification, client implementations MUST support 226 configuring, for each transport receiver, the name to be matched 227 against the certificate. This name may be the host name or IP 228 address used when opening the TCP connection. Implementations MUST 229 support checking the hostname against a SubjectAltName field with a 230 type of dNSName and SHOULD support checking hostname against the 231 Common Name portion of the Subject Distinguished Name. Matching for 232 certificate credentials is performed using the matching rules 233 specified by [3]. If more than one identity of a given type is 234 presented in the certificate (e.g., more than one dNSName name), a 235 match in any one of the set is considered acceptable. 236 Implementations MAY support other authorization processes matching 237 against other fields in a certificate. Implementations also MAY 238 support wildcards to match a range of values. For example, names to 239 be matched against a certificate may contain the wildcard character * 240 which is considered to match any single domain name component or 241 component fragment. E.g., *.a.com matches foo.a.com but not 242 bar.foo.a.com. f*.com matches foo.com but not bar.com. 244 [Editor's Note: How useful is it to match against IP address? Do we 245 expect deployments to issue certificates with IP addresses in them? 246 Are IP addresses typically used in configuration? ] 248 To support certificate fingerprints, client implementations MUST 249 support configuring, for each transport receiver, a fingerprint of 250 the server certificate. See Section 4.2.3 for details. 252 If the certificate fails authorization or validity checks, clients 253 SHOULD log the error in some form or another (see next paragraph), 254 and SHOULD terminate the connection with a bad certificate error. 256 The application developer must take some care to consider the case 257 when, for whatever reason, there is a problem with authenticating the 258 other end of the connection. Since this problem will prevent log 259 messages from being transmitted, each device having this problem 260 should use whatever means are available to inform the administrator 261 of the problem. This may include producing an error code on a 262 console, returning an error to a user (if there is one), or writing a 263 file to disk, being mindful that such writes should be rate limited 264 in the case of attacks. 266 4.2.2. Client Authentication and Authorization 268 The transport receiver (TLS server) has three different options for 269 authenticating and authorizing the transport sender (TLS client). 271 [Editor's note: At least one one authorization mechanism should be 272 mandatory to implement to protect against the threat of masquerade 273 listed above.] 275 o Certification path validation and subject name verification: the 276 server is configured with one or more trust anchors, and a set of 277 names (or wildcard patterns) to be matched against the 278 certificates. This option MUST be supported. 280 o Certificate fingerprints: The server is configured with the 281 fingerprints of client certificates. This option MUST be 282 supported. 284 o No client authentication or authorization (or authorization based 285 only on connection source IP address): This option MAY be 286 supported, but MUST NOT be enabled by default. 288 Certification path validation and subject name verification work as 289 described in Section Section 4.2.2 above. A server may allow wild 290 card names to match against the certificate which will result in a 291 large number of clients with valid certificates to be authorized. 292 Servers SHOULD provide a mechanism to log the identity and issuer of 293 an accepted certificate to enable messages received from the client 294 to be associated with an authenticated entity. 296 To support certificate fingerprints, server implementations MUST 297 support configuring with a list of fingerprints of authorized 298 certificates. See Section Section 4.2.3 for details. 300 [Editor's note: Removed section on using the same name for more that 301 one host as it seems implementation specific. Removed section on 302 discussion on who issues the certificate since it is out of scope.] 304 4.2.3. Certificate Fingerprints 306 Both client and server implementations MUST make the certificate 307 fingerprint available through a management interface. If no other 308 certificate is configured, both client and server implementations 309 MUST support generating a key pair and self-signed certificate. 311 The RECOMMENDED mechanism to generate a fingerprint is to take the 312 SHA-1 hash of the certificate and convert the 20 byte result into 20 313 colon separated, hexadecimal bytes, each represented by 2 uppercase 314 ASCII characters. When a fingerprint value is displayed or 315 configured the algorithm used to generate the fingerprint SHOULD be 316 indicated. 318 4.2.4. Cryptographic Level 320 Syslog applications SHOULD be implemented in a manner that permits 321 administrators, as a matter of local policy, to select the 322 cryptographic level and authentication options they desire. 324 TLS permits the resumption of an earlier TLS session or the use of 325 another active session when a new session is requested, in order to 326 save the expense of another full TLS handshake. The security 327 parameters of the resumed session are reused for the requested 328 session. The security parameters SHOULD be checked against the 329 security requirement of the requested session to make sure that the 330 resumed session provides proper security. 332 4.3. Sending data 334 All syslog messages MUST be sent as TLS "application data". It is 335 possible that multiple syslog messages be contained in one TLS 336 record, or that a syslog message be transferred in multiple TLS 337 records. The application data is defined with the following ABNF [4] 338 expression: 340 APPLICATION-DATA = 1*SYSLOG-FRAME 342 SYSLOG-FRAME = MSG-LEN SP SYSLOG-MSG 344 MSG-LEN = NONZERO-DIGIT *DIGIT 346 SP = %d32 348 NONZERO-DIGIT = %d49-57 350 DIGIT = %d48 / NONZERO-DIGIT 352 SYSLOG-MSG is defined in syslog [2] protocol. 354 4.3.1. Message Length 356 The message length is the octet count of the SYSLOG-MSG in the 357 SYSLOG-FRAME. A transport receiver MUST use the message length to 358 delimit a syslog message. There is no upper limit for a message 359 length per se. However, in order to establish a baseline for 360 interoperability, this specification requires that a transport 361 receiver MUST be able to process messages with a length up to and 362 including 2048 octets. Transport receiver SHOULD be able to process 363 messages with lengths up to and including 8192 octets. 365 4.4. Closure 367 A TLS client MUST close the associated TLS connection if the 368 connection is not expected to deliver any syslog messages later. It 369 MUST send a TLS close_notify alert before closing the connection. A 370 client MAY choose to not wait for the server's close_notify alert and 371 simply close the connection, thus generating an incomplete close on 372 the server side. Once the server gets a close_notify from the 373 client, it MUST reply with a close_notify unless it becomes aware 374 that the connection has already been closed by the client (e.g., the 375 closure was indicated by TCP). 377 When no data is received from a connection for a long time (where the 378 application decides what "long" means), a server MAY close the 379 connection. The server MUST attempt to initiate an exchange of 380 close_notify alerts with the client before closing the connection. 381 Servers that are unprepared to receive any more data MAY close the 382 connection after sending the close_notify alert, thus generating an 383 incomplete close on the client side. When the client has received 384 the close_notify alert from the server and still has pending data to 385 send, it SHOULD send the pending data before sending the close_notify 386 alert. 388 5. Security Considerations 390 5.1. Authentication and Certificates 392 In security sensitive environments, it is recommended that mutual 393 authentication be deployed as that will prevent masquerade attacks, 394 modification of the messages, and disclosure of the contents of the 395 messages. Mutual authentication means the TLS client and server are 396 provisioned with necessary trust anchors and must perform certificate 397 validation. 399 [Editor's Note: added text on self-signed certificate validation and 400 removed text on caching.] 402 The use of self-signed certificates with certificate fingerprint 403 authorization lists provides more protection from masquerade and man- 404 in-the-middle attacks than forgoing certificate validation and 405 authorization. 407 [Editor's Note: It may be useful to suggest some operational practice 408 that facilitates the deployment of self-signed certificates. For 409 example, in order to initially populate an authorization list a 410 client or server can display a certificate finger-print through a 411 user interface to an administrator to be authorized and added to the 412 authorization list.] 414 If the client or server choose to forgo certificate validation then 415 the threats listed in Section 2 may not be appropriately mitigated. 416 Malicious entities may masquerade as the client or server, or they 417 may insert themselves as a man-in-the middle of the conversation. 418 This may result in modification and disclosure of data. While this 419 may be acceptable in a security insensitive environment, it is 420 recommended that server and client are configured with certificates 421 and validate received certificate against provisioned trust anchors 422 and authorization lists. 424 TLS authentication and the distribution of keys is based on 425 certificates and asymmetric cryptography. This makes TLS transport 426 more expensive than non-TLS plain transport. An attacker may 427 initialize many TLS connections to a receiver as a denial of service 428 attack. Since a receiver may act upon received data, for syslog over 429 TLS, it is recommended that the server authenticate the client to 430 ensure that information received is authentic. 432 5.2. Cipher Suites 434 This specification specifies the following cipher suite required for 435 all compliant implementation for minimum interoperability purposes: 437 TLS_RSA_WITH_AES_128_CBC_SHA 439 Operators MAY choose to disable cipher suites for TLS that are 440 regarded as too weak for the environment in which this specification 441 is being used, especially older cipher suites. This MAY lead to a 442 reduction of interoperability. It is likely that, in time, the 443 cipher suite specified here will become subject to attack and the use 444 of it will too be deprecated. This allows the future update of the 445 specification to change mandatory-to-implement cipher requirement for 446 interoperability. This also allows the TLS community to change its 447 recommendations, and operators to follow those recommendations. 449 The implementers and deployers should be aware of the strengths of 450 the public keys algorithm in the suite for exchanging symmetric keys, 451 which is elaborated in BCP86 [6]. The implementers and deployers 452 should also be aware of the latest TLS and other IETF cryptography 453 standards including BCP86. 455 6. IANA Considerations 457 6.1. Port Number 459 IANA is requested to assign a TCP port number in the range 1..1023 in 460 the http://www.iana.org/assignments/port-numbers registry which will 461 be the default port for syslog over TLS, as defined in this document. 463 7. Acknowledgments 465 Authors appreciate Eric Rescorla, Rainer Gerhards, Tom Petch, Anton 466 Okmianski, Balazs Scheidler, Bert Wijnen, and Chris Lonvick for their 467 effort on issues resolving discussion. Authors would also like to 468 appreciate Balazs Scheidler, Tom Petch and other persons for their 469 input on security threats of syslog. The authors would like to 470 acknowledge David Harrington for his detailed reviews of the content 471 and grammar of the document and Pasi Eronen for his contributions to 472 certificate authentication and authorization sections. 474 8. References 476 8.1. Normative References 478 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 479 Levels", BCP 14, RFC 2119, March 1997. 481 [2] Gerhards, R., "The syslog Protocol", 482 draft-ietf-syslog-protocol-23 (work in progress), 483 September 2007. 485 [3] Cooper, D., "Internet X.509 Public Key Infrastructure 486 Certificate and Certificate Revocation List (CRL) Profile", 487 draft-ietf-pkix-rfc3280bis-11 (work in progress), February 2008. 489 [4] Crocker, D. and P. Overell, "Augmented BNF for Syntax 490 Specifications: ABNF", STD 68, RFC 5234, January 2008. 492 [5] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) 493 Protocol Version 1.2", draft-ietf-tls-rfc4346-bis-10 (work in 494 progress), March 2008. 496 8.2. Informative References 498 [6] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys 499 Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, 500 April 2004. 502 Authors' Addresses 504 Fuyou Miao (editor) 505 Huawei Technologies 506 No. 3, Xinxi Rd 507 Shangdi Information Industry Base 508 Haidian District, Beijing 100085 509 P. R. China 511 Phone: +86 10 8288 2008 512 Email: miaofy@huawei.com 513 URI: www.huawei.com 515 Yuzhi Ma (editor) 516 Huawei Technologies 517 No. 3, Xinxi Rd 518 Shangdi Information Industry Base 519 Haidian District, Beijing 100085 520 P. R. China 522 Phone: +86 10 8288 2008 523 Email: myz@huawei.com 524 URI: www.huawei.com 526 Joseph Salowey (editor) 527 Cisco Systems, Inc. 528 2901 3rd. Ave 529 Seattle, WA 98121 530 USA 532 Email: jsalowey@cisco.com 534 Full Copyright Statement 536 Copyright (C) The IETF Trust (2008). 538 This document is subject to the rights, licenses and restrictions 539 contained in BCP 78, and except as set forth therein, the authors 540 retain all their rights. 542 This document and the information contained herein are provided on an 543 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 544 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 545 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 546 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 547 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 548 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 550 Intellectual Property 552 The IETF takes no position regarding the validity or scope of any 553 Intellectual Property Rights or other rights that might be claimed to 554 pertain to the implementation or use of the technology described in 555 this document or the extent to which any license under such rights 556 might or might not be available; nor does it represent that it has 557 made any independent effort to identify any such rights. Information 558 on the procedures with respect to rights in RFC documents can be 559 found in BCP 78 and BCP 79. 561 Copies of IPR disclosures made to the IETF Secretariat and any 562 assurances of licenses to be made available, or the result of an 563 attempt made to obtain a general license or permission for the use of 564 such proprietary rights by implementers or users of this 565 specification can be obtained from the IETF on-line IPR repository at 566 http://www.ietf.org/ipr. 568 The IETF invites any interested party to bring to its attention any 569 copyrights, patents or patent applications, or other proprietary 570 rights that may cover technology that may be required to implement 571 this standard. Please address the information to the IETF at 572 ietf-ipr@ietf.org. 574 Acknowledgment 576 Funding for the RFC Editor function is provided by the IETF 577 Administrative Support Activity (IASA).