idnits 2.17.1 draft-ietf-syslog-transport-tls-14.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 641. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 652. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 659. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 665. 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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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 (September 30, 2008) is 5658 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 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-29) exists of draft-ietf-syslog-sign-23 -- Obsolete informational reference (is this intentional?): RFC 4572 (Obsoleted by RFC 8122) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 8 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: April 3, 2009 J. Salowey, Ed. 6 Cisco Systems, Inc. 7 September 30, 2008 9 TLS Transport Mapping for Syslog 10 draft-ietf-syslog-transport-tls-14.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 April 3, 2009. 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. Using 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. Certificate-Based Authentication . . . . . . . . . . . 5 58 4.2.2. Certificate Fingerprints . . . . . . . . . . . . . . . 6 59 4.2.3. Cryptographic Level . . . . . . . . . . . . . . . . . 7 60 4.3. Sending data . . . . . . . . . . . . . . . . . . . . . . . 7 61 4.3.1. Message Length . . . . . . . . . . . . . . . . . . . . 7 62 4.4. Closure . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 5. Security Policies . . . . . . . . . . . . . . . . . . . . . . 8 64 5.1. End-Entity Certificate Based Authorization . . . . . . . . 8 65 5.2. Subject Name Authorization . . . . . . . . . . . . . . . . 9 66 5.3. Unauthenticated Transport Sender . . . . . . . . . . . . . 9 67 5.4. Unauthenticated Transport Receiver . . . . . . . . . . . . 10 68 5.5. Unauthenticated Transport Receiver and Sender . . . . . . 10 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 70 6.1. Authentication and Authorization Policies . . . . . . . . 10 71 6.2. Name Validation . . . . . . . . . . . . . . . . . . . . . 11 72 6.3. Reliability . . . . . . . . . . . . . . . . . . . . . . . 11 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 74 7.1. Port Number . . . . . . . . . . . . . . . . . . . . . . . 11 75 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 76 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 78 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 79 Appendix A. Changes from -12 . . . . . . . . . . . . . . . . . . 12 80 Appendix B. Changes from -13 . . . . . . . . . . . . . . . . . . 13 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 82 Intellectual Property and Copyright Statements . . . . . . . . . . 15 84 1. Introduction 86 This document describes the use of Transport Layer Security (TLS 87 [RFC5246]) to provide a secure connection for the transport of syslog 88 [I-D.ietf-syslog-protocol] messages. This document describes the 89 security threats to syslog and how TLS can be used to counter such 90 threats. 92 1.1. Terminology 94 The following definitions are used in this document: 96 o An "originator" generates syslog content to be carried in a 97 message. 99 o A "collector" gathers syslog content for further analysis. 101 o A "relay" forwards messages, accepting messages from originators 102 or other relays, and sending them to collectors or other relays. 104 o A "transport sender" passes syslog messages to a specific 105 transport protocol. 107 o A "transport receiver" takes syslog messages from a specific 108 transport protocol. 110 o A "TLS client" is an application that can initiate a TLS 111 connection by sending a Client Hello to a server. 113 o A "TLS server" is an application that can receive a Client Hello 114 from a client and reply with a Server Hello. 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in RFC 2119 [RFC2119]. 120 2. Security Requirements for Syslog 122 Syslog messages may transit several hops to arrive at the intended 123 collector. Some intermediary networks may not be trusted by the 124 originator, relay, or receiver because the network is in a different 125 security domain or at a different security level from the originator, 126 relay, or collector. Another security concern is that the 127 originator, relay, or receiver itself is in an insecure network. 129 There are several threats to be addressed for syslog security. The 130 primary threats are: 132 o Masquerade. An unauthorized transport sender may send messages to 133 a legitimate transport receiver, or an unauthorized transport 134 receiver tries to deceive a legitimate transport sender into 135 sending syslog messages to it. 137 o Modification. An attacker between the transport sender and the 138 transport receiver may modify an in-transit syslog message and 139 then forward the message to the transport receiver. Such 140 modification may make the transport receiver misunderstand the 141 message or cause it to behave in undesirable ways. 143 o Disclosure. An unauthorized entity may examine the contents of 144 the syslog messages, gaining unauthorized access to the 145 information. Some data in syslog messages is sensitive and may be 146 useful to an attacker, such as the password of an authorized 147 administrator or user. 149 The secondary threat is: 151 o Message stream modification. An attacker may delete one or more 152 syslog message from a series of messages, replay a message, or 153 alter the delivery sequence. The syslog protocol itself is not 154 based on message order, but an event in a syslog message may 155 relate semantically to events in other messages, so message 156 ordering may be important to understanding a sequence of events. 158 The following threats are deemed to be of lesser importance for 159 syslog, and are not addressed in this document: 161 o Denial of Service 163 o Traffic Analysis 165 3. Using TLS to Secure Syslog 167 TLS can be used as a secure transport to counter all the primary 168 threats to syslog described above: 170 o Confidentiality to counter disclosure of the message contents; 172 o Integrity checking to counter modifications to a message on a hop- 173 by-hop basis; 175 o Server or mutual authentication to counter masquerade. 177 Note: This secure transport (i.e., TLS) only secures syslog transport 178 in a hop-by-hop manner, and is not concerned with the contents of 179 syslog messages. In particular, the authenticated identity of the 180 transport sender (e.g., subject name in the certificate) is not 181 necessarily related to the HOSTNAME field of the syslog message. 182 When authentication of syslog message origin is required, 183 [I-D.ietf-syslog-sign] can be used. 185 4. Protocol Elements 187 4.1. Port Assignment 189 A syslog transport sender is always a TLS client and a transport 190 receiver is always a TLS server. 192 The TCP port NNN has been allocated as the default port for syslog 193 over TLS, as defined in this document. 195 Note to RFC Editor: please replace NNN with the IANA-assigned value, 196 and remove this note. 198 4.2. Initiation 200 The transport sender should initiate a connection to the transport 201 receiver and then send the TLS Client Hello to begin the TLS 202 handshake. When the TLS handshake has finished the transport sender 203 MAY then send the first syslog message. 205 TLS typically uses certificates [RFC5280] to authenticate peers. 206 Implementations MUST support TLS 1.2 [RFC5246] and are REQUIRED to 207 support the mandatory to implement cipher suite, which is 208 TLS_RSA_WITH_AES_128_CBC_SHA. This document is assumed to apply to 209 future versions of TLS, in which case the mandatory to implement 210 cipher suite for the implemented version MUST be supported. 212 4.2.1. Certificate-Based Authentication 214 Both syslog transport sender (TLS Client) and syslog transport 215 receiver (TLS server) MUST implement certificate-based 216 authentication. This consists of validating the certificate and 217 verifying that the peer has the corresponding private key. The 218 latter part is performed by TLS. To ensure interoperability between 219 clients and servers, the following methods for certificate validation 220 SHALL be implemented: 222 o Certification path validation: The TLS peer is configured with one 223 or more trust anchors (typically root CA certificates), which 224 allow it to verify a binding between the subject name and the 225 public key. Additional policy controls needed for authorizing the 226 syslog transport sender and receiver (i.e., verifying that the 227 subject name represents an authorized party) are described in 228 Section 5. Certificate path validation is performed as defined in 229 [RFC5280]. This method is useful where there is a PKI deployment. 231 o End-entity certificate matching: The transport sender or receiver 232 is configured with information necessary to identify the valid 233 end-entity certificates of its authorized peers. The end-entity 234 certificates can be self-signed, and no certification path 235 validation is needed. Implementations MUST support certificate 236 fingerprints in Section 4.2.2 and MAY allow other formats for end- 237 entity certificates such as a DER encoded certificate. This 238 method provides an alternative to a PKI that is simple to deploy 239 and still maintains a reasonable level of security. 241 Both transport receiver and transport sender implementations MUST 242 provide a means to generate a key pair and self-signed certificate in 243 the case that a key pair and certificate are not available through 244 another mechanism. 246 The transport receiver and transport sender SHOULD provide mechanisms 247 to record the end-entity certificate for the purpose of correlating 248 it with the sent or received data. 250 4.2.2. Certificate Fingerprints 252 Both client and server implementations MUST make the certificate 253 fingerprints for their certificate available through a management 254 interface. The labels for the algorithms are taken from the textual 255 names of the hash functions as defined in the IANA registry "Hash 256 Function Textual Names" allocated in [RFC4572]. 258 The mechanism to generate a fingerprint is to take the hash of the 259 DER-encoded certificate using a cryptographically strong algorithm 260 and convert the result into colon separated, hexadecimal bytes, each 261 represented by 2 uppercase ASCII characters. When a fingerprint 262 value is displayed or configured the fingerprint is prepended with an 263 ASCII label identifying the hash function followed by a colon. 264 Implementations MUST support SHA-1 as the hash algorithm and use the 265 ASCII label "sha-1" to identify the SHA-1 algorithm. The length of a 266 SHA-1 hash is 20 bytes and the length of the corresponding 267 fingerprint string is 65 characters. An example certificate 268 fingerprint is: 270 sha-1:E1:2D:53:2B:7C:6B:8A:29:A2:76:C8:64:36:0B:08:4B:7A:F1:9E:9D 272 During validation the hash is extracted from the fingerprint and 273 compared against the hash calculated over the received certificate. 275 4.2.3. Cryptographic Level 277 Syslog applications SHOULD be implemented in a manner that permits 278 administrators, as a matter of local policy, to select the 279 cryptographic level and authentication options they desire. 281 TLS permits the resumption of an earlier TLS session or the use of 282 another active session when a new session is requested, in order to 283 save the expense of another full TLS handshake. The security 284 parameters of the resumed session are reused for the requested 285 session. The security parameters SHOULD be checked against the 286 security requirement of the requested session to make sure that the 287 resumed session provides proper security. 289 4.3. Sending data 291 All syslog messages MUST be sent as TLS "application data". It is 292 possible that multiple syslog messages be contained in one TLS 293 record, or that a syslog message be transferred in multiple TLS 294 records. The application data is defined with the following ABNF 295 [RFC5234] expression: 297 APPLICATION-DATA = 1*SYSLOG-FRAME 299 SYSLOG-FRAME = MSG-LEN SP SYSLOG-MSG 301 MSG-LEN = NONZERO-DIGIT *DIGIT 303 SP = %d32 305 NONZERO-DIGIT = %d49-57 307 DIGIT = %d48 / NONZERO-DIGIT 309 SYSLOG-MSG is defined in syslog [I-D.ietf-syslog-protocol] protocol. 311 4.3.1. Message Length 313 The message length is the octet count of the SYSLOG-MSG in the 314 SYSLOG-FRAME. A transport receiver MUST use the message length to 315 delimit a syslog message. There is no upper limit for a message 316 length per se. However, in order to establish a baseline for 317 interoperability, this specification requires that a transport 318 receiver MUST be able to process messages with a length up to and 319 including 2048 octets. Transport receiver SHOULD be able to process 320 messages with lengths up to and including 8192 octets. 322 4.4. Closure 324 A transport sender MUST close the associated TLS connection if the 325 connection is not expected to deliver any syslog messages later. It 326 MUST send a TLS close_notify alert before closing the connection. A 327 transport sender (TLS client) MAY choose to not wait for the 328 transport receiver's close_notify alert and simply close the 329 connection, thus generating an incomplete close on the transport 330 receiver (TLS server) side. Once the transport receiver gets a 331 close_notify from the transport sender, it MUST reply with a 332 close_notify unless it becomes aware that the connection has already 333 been closed by the transport sender (e.g., the closure was indicated 334 by TCP). 336 When no data is received from a connection for a long time (where the 337 application decides what "long" means), a transport receiver MAY 338 close the connection. The transport receiver (TLS server) MUST 339 attempt to initiate an exchange of close_notify alerts with the 340 transport sender before closing the connection. Transport receivers 341 that are unprepared to receive any more data MAY close the connection 342 after sending the close_notify alert, thus generating an incomplete 343 close on the transport sender side. 345 5. Security Policies 347 Different environments have different security requirements and 348 therefore would deploy different security policies. This section 349 discusses some of the security policies that may be implemented by 350 syslog transport receivers and syslog transport senders. The 351 security policies describe the requirements for authentication and 352 authorization. The list of policies in this section is not 353 exhaustive and other policies MAY be implemented. 355 If the peer does not meet the requirements of the security policy, 356 the TLS handshake MUST be aborted with an appropriate TLS alert. 358 5.1. End-Entity Certificate Based Authorization 360 In the simplest case, the transport sender and receiver are 361 configured with information necessary to identity the valid end- 362 entity certificates of its authorized peers. 364 Implementations MUST support specifying the authorized peers using 365 certificate fingerprints, as described in Section 4.2.1 and 366 Section 4.2.2. 368 5.2. Subject Name Authorization 370 Implementations MUST support certification path validation [RFC5280]. 371 In addition they MUST support specifying the authorized peers using 372 locally configured host names and matching the name against the 373 certificate as follows. 375 o Implementations MUST support matching the locally configured host 376 name against a dNSName in the subjectAltName extension field and 377 SHOULD support checking the name against the common name portion 378 of the subject distinguished name. 380 o The '*' (ASCII 42) wildcard character is allowed in the dNSName of 381 the subjectAltName extension (and in common name, if used to store 382 the host name), and then only as the left-most (least significant) 383 DNS label in that value. This wildcard matches any left-most DNS 384 label in the server name. That is, the subject *.example.com 385 matches the server names a.example.com and b.example.com, but does 386 not match example.com or a.b.example.com. Implementations MUST 387 support wildcards in certificates as specified above, but MAY 388 provide a configuration option to disable them. 390 o Locally configured names MAY contain the wildcard character to 391 match a range of values. The types of wildcards supported MAY be 392 more flexible than that which is allowed in subject names to make 393 it possible to support various policies for different 394 environments. For example, a policy could allow for a trust-root- 395 based authorization where all credentials issued by a particular 396 CA trust root are authorized. 398 o If the locally configured name is an internationalized domain 399 name, conforming implementations MUST convert it to the ASCII 400 Compatible Encoding (ACE) format for performing comparisons as 401 specified in Section 7 of [RFC5280]. 403 o Implementations MAY support matching a locally configured IP 404 address against an iPAddress stored in the subjectAltName 405 extension. In this case, the locally configured IP address is 406 converted to an octet string as specified in [RFC5280], Section 407 4.2.1.6. A match occurs if this octet string is equal to the 408 value of iPAddress in the subjectAltName extension. 410 5.3. Unauthenticated Transport Sender 412 In some environments, the authenticity of syslog data is not 413 important or it is verifiable by other means, so transport receivers 414 may accept data from any transport sender. To achieve this, the 415 transport receiver can skip transport sender authentication (by not 416 requesting client authentication in TLS, or accepting any 417 certificate). In this case, the transport receiver is authenticated 418 and authorized, however this policy does not protect against the 419 threat of transport sender masquerade described in Section 2. The 420 use of this policy is generally NOT RECOMMENDED for this reason. 422 5.4. Unauthenticated Transport Receiver 424 In some environments the confidentiality of syslog data is not 425 important so messages are sent to any transport receiver. To achieve 426 this, the transport sender can skip transport receiver authentication 427 (by accepting any certificate). While this policy does authenticate 428 and authorize the transport sender, it does not protect against the 429 threat of transport receiver masquerade described in Section 2, 430 leaving the data sent vulnerable to disclosure and modification. The 431 use of this policy is generally NOT RECOMMENDED for this reason. 433 5.5. Unauthenticated Transport Receiver and Sender 435 In environments where security is not a concern at all, both the 436 transport receiver and transport sender can skip authentication (as 437 described in Sections 5.3 and 5.4). This policy does not protect 438 against any of the threats described in Section 2 and is therefore 439 NOT RECOMMENDED. 441 6. Security Considerations 443 This section describes security considerations in addition to those 444 in [RFC5246]. 446 6.1. Authentication and Authorization Policies 448 Section 5 discusses various security policies that may be deployed. 449 The threats in Section 2 are mitigated only if both the transport 450 sender and transport receiver are properly authenticated and 451 authorized, as described in Section 5.1 and Section 5.2. These are 452 the RECOMMENDED configurations for a default policy. 454 If the transport receiver does not authenticate the transport sender 455 it may accept data from an attacker. Unless it has another way of 456 authenticating the source of the data, the data should not be 457 trusted. This is especially important if the syslog data is going to 458 be used to detect and react to security incidents. The transport 459 receiver may also increase its vulnerability to denial of service, 460 resource consumption and other attacks if it does not authenticate 461 the transport sender. Because of the increased vulnerability to 462 attack, this type of configuration is NOT RECOMMENDED. 464 If the transport sender does not authenticate the syslog transport 465 receiver then it may send data to an attacker. This may disclose 466 sensitive data within the log information that is useful to an 467 attacker resulting in further compromises within the system. If a 468 transport sender is operated in this mode, the data sent SHOULD be 469 limited to data that is not valuable to an attacker. In practice 470 this is very difficult to achieve, so this type of configuration is 471 NOT RECOMMENDED. 473 Forgoing authentication and authorization on both sides allows for 474 man-in-the-middle, masquerade and other types of attacks that can 475 completely compromise integrity and confidentiality of the data. 476 This type of configuration is NOT RECOMMENDED. 478 6.2. Name Validation 480 The subject name authorization policy authorizes the subject in the 481 certificate against a locally configured name. It is generally not 482 appropriate to obtain this name through some other means such as DNS 483 lookup since this introduces additional security vulnerabilities. 485 6.3. Reliability 487 It should be noted that the syslog transport specified in this 488 document does not use application-layer acknowledgments. TCP uses 489 retransmissions to provide protection against some forms of data 490 loss. However, if the TCP connection (or TLS session) is broken for 491 some reason (or closed by the transport receiver), the syslog 492 transport sender cannot always know what messages were successfully 493 delivered to the syslog application at the other end. 495 7. IANA Considerations 497 7.1. Port Number 499 IANA is requested to assign a TCP port number in the "Registered Port 500 Numbers" range with the name "syslog-tls". This port will be the 501 default port for syslog over TLS, as defined in this document. 503 8. Acknowledgments 505 Authors appreciate Eric Rescorla, Rainer Gerhards, Tom Petch, Anton 506 Okmianski, Balazs Scheidler, Bert Wijnen, Martin Schuette, Chris 507 Lonvick and members of the syslog working group for their effort on 508 issues resolving discussion. Authors would also like to appreciate 509 Balazs Scheidler, Tom Petch and other persons for their input on 510 security threats of syslog. The authors would like to acknowledge 511 David Harrington for his detailed reviews of the content and grammar 512 of the document and Pasi Eronen for his contributions to certificate 513 authentication and authorization sections. 515 9. References 517 9.1. Normative References 519 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 520 Requirement Levels", BCP 14, RFC 2119, March 1997. 522 [I-D.ietf-syslog-protocol] 523 Gerhards, R., "The syslog Protocol", 524 draft-ietf-syslog-protocol-23 (work in progress), 525 September 2007. 527 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 528 Housley, R., and W. Polk, "Internet X.509 Public Key 529 Infrastructure Certificate and Certificate Revocation List 530 (CRL) Profile", RFC 5280, May 2008. 532 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 533 Specifications: ABNF", STD 68, RFC 5234, January 2008. 535 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 536 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 538 9.2. Informative References 540 [I-D.ietf-syslog-sign] 541 Kelsey, J., "Signed syslog Messages", 542 draft-ietf-syslog-sign-23 (work in progress), 543 October 2007. 545 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 546 Transport Layer Security (TLS) Protocol in the Session 547 Description Protocol (SDP)", RFC 4572, July 2006. 549 Appendix A. Changes from -12 551 Please remove in published RFC. 553 Section 3: Expanded note to include reference to Syslog Sign. 555 Section 4.2: Included mandatory to implement ciphersuites that 556 track future versions of the TLS 558 Section 4.2.1: Revised to certificate based authentication 559 mechanisms. authorization policy is covered in section 5. 561 Section 4.2.2: added to describe fingerprint format 563 Section 5: new security policies section 565 Security Considerations: added reference to TLS security 566 considerations, removed cipher suite section which was redundant 567 with TLS 569 Added redundancy and name validation to security considerations 570 section 572 Appendix B. Changes from -13 574 Please remove in published RFC. 576 Section 1.1: Cleaned up definition of TLS client and TLS server 578 Section 4.2.2: Changed certificate fingerprint section to 579 reference hash registry (changed "SHA-1" to "sha-1" 581 Section 4.4: Clarified transport receiver and transport sender 582 language. Removed last sentence on sending pending data after 583 close. 585 Section 5: changed SHOULD be aborted to MUST be aborted 587 Section 5.2: replaced text with bullets enumerating requirements 589 Section 5.5: Fixed section references 591 Section 7.1: change IANA assignment to registered port 593 Section 8: Fixed the spelling of Martin's name 595 Authors' Addresses 597 Fuyou Miao (editor) 598 Huawei Technologies 599 No. 3, Xinxi Rd 600 Shangdi Information Industry Base 601 Haidian District, Beijing 100085 602 P. R. China 604 Phone: +86 10 8288 2008 605 Email: miaofy@huawei.com 606 URI: www.huawei.com 608 Yuzhi Ma (editor) 609 Huawei Technologies 610 No. 3, Xinxi Rd 611 Shangdi Information Industry Base 612 Haidian District, Beijing 100085 613 P. R. China 615 Phone: +86 10 8288 2008 616 Email: myz@huawei.com 617 URI: www.huawei.com 619 Joseph Salowey (editor) 620 Cisco Systems, Inc. 621 2901 3rd. Ave 622 Seattle, WA 98121 623 USA 625 Email: jsalowey@cisco.com 627 Full Copyright Statement 629 Copyright (C) The IETF Trust (2008). 631 This document is subject to the rights, licenses and restrictions 632 contained in BCP 78, and except as set forth therein, the authors 633 retain all their rights. 635 This document and the information contained herein are provided on an 636 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 637 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 638 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 639 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 640 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 641 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 643 Intellectual Property 645 The IETF takes no position regarding the validity or scope of any 646 Intellectual Property Rights or other rights that might be claimed to 647 pertain to the implementation or use of the technology described in 648 this document or the extent to which any license under such rights 649 might or might not be available; nor does it represent that it has 650 made any independent effort to identify any such rights. Information 651 on the procedures with respect to rights in RFC documents can be 652 found in BCP 78 and BCP 79. 654 Copies of IPR disclosures made to the IETF Secretariat and any 655 assurances of licenses to be made available, or the result of an 656 attempt made to obtain a general license or permission for the use of 657 such proprietary rights by implementers or users of this 658 specification can be obtained from the IETF on-line IPR repository at 659 http://www.ietf.org/ipr. 661 The IETF invites any interested party to bring to its attention any 662 copyrights, patents or patent applications, or other proprietary 663 rights that may cover technology that may be required to implement 664 this standard. Please address the information to the IETF at 665 ietf-ipr@ietf.org. 667 Acknowledgment 669 Funding for the RFC Editor function is provided by the IETF 670 Administrative Support Activity (IASA).