idnits 2.17.1 draft-ietf-rap-cops-tls-09.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 3667, Section 5.1 on line 502. -- Found old boilerplate from RFC 3978, Section 5.5 on line 542. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 513. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 520. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 526. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The abstract seems to indicate that this document updates RFC2748, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- 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 24, 2004) is 7154 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) == Missing Reference: 'RFC3667' is mentioned on line 18, but not defined ** Obsolete undefined reference: RFC 3667 (Obsoleted by RFC 3978) == Missing Reference: 'RFC2753' is mentioned on line 90, but not defined == Unused Reference: 'RFC2026' is defined on line 450, but no explicit reference was found in the text == Unused Reference: 'RFC3207' is defined on line 474, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) Summary: 8 errors (**), 0 flaws (~~), 7 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Jesse Walker 3 Expiration: March 2005 Amol Kulkarni, Ed. 4 File: draft-ietf-rap-cops-tls-09.txt Intel Corp. 6 COPS Over TLS 8 Last Updated: September 24, 2004 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of section 3 of RFC 3667 [RFC3667]. By submitting this Internet- 14 Draft, each author represents that any applicable patent or other 15 IPR claims of which he or she is aware have been or will be 16 disclosed, and any of which he or she become aware will be 17 disclosed, in accordance with RFC 3668. 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 25 months and may be updated, replaced, or obsoleted by other 26 documents at any time. It is inappropriate to use Internet-Drafts 27 as reference material or to cite them other than as "work in 28 progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Conventions used in this document 38 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 39 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 40 this document are to be interpreted as described in RFC 2119 41 [RFC2119]. 43 Abstract 45 This document describes how to use Transport Layer Security (TLS) 46 to secure Common Open Policy Service (COPS) connections over the 47 Internet. 49 This document also updates RFC 2748 by modifying the contents of 50 the Client-Accept message. 52 Table Of Contents 54 Glossary..........................................................3 55 1 Introduction...................................................3 56 2 COPS Over TLS..................................................3 57 3 Separate Ports versus Upward Negotiation.......................3 58 4 COPS/TLS Objects and Error codes...............................4 59 4.1 The Security ClientSI Object..................................4 60 4.2 Error Codes...................................................4 61 5 COPS/TLS Secure Connection Initiation..........................4 62 5.1 PEP Initiated Security Negotiation............................5 63 5.2 PDP Initiated Security Negotiation............................5 64 6 Connection Closure.............................................6 65 6.1 PEP System Behavior...........................................6 66 6.2 PDP System Behavior...........................................7 67 7 Endpoint Identification and Access Control.....................7 68 7.1 PDP Identity..................................................8 69 7.2 PEP Identity..................................................8 70 8 Backward Compatibility.........................................9 71 9 IANA Considerations.............................................9 72 10 Security Considerations........................................9 73 11 References.....................................................9 74 11.1 Normative References........................................10 75 11.2 Informative References......................................10 76 12 Author Addresses.............................................10 77 13 IPR Disclosure Acknowledgement...............................10 78 14 Disclaimer of Validity.......................................11 79 15 Copyright Statement..........................................11 80 16 Disclaimer...................................................11 81 17 Acknowledgements.............................................11 83 Glossary 84 COPS - Common Open Policy Service. See [RFC2748]. 85 COPS/TCP - A plain-vanilla implementation of COPS. 86 COPS/TLS - A secure implementation of COPS using TLS. 87 PDP - Policy Decision Point. Also referred to as the Policy 88 Server. See [RFC2753]. 89 PEP - Policy Enforcement Point. Also referred to as the Policy 90 Client. See [RFC2753]. 92 1 Introduction 94 COPS [RFC2748] was designed to distribute clear-text policy 95 information from a centralized Policy Decision Point (PDP) to a set 96 of Policy Enforcement Points (PEP) in the Internet. COPS provides 97 its own security mechanisms to protect the per-hop integrity of the 98 deployed policy. However, the use of COPS for sensitive applications 99 such as some types of security policy distribution requires 100 additional security measures, such as data privacy. This is because 101 some organizations find it necessary to hide some or all of their 102 security policies, e.g., because policy distribution to devices such 103 as mobile platforms can cross domain boundaries. 105 TLS [RFC2246] was designed to provide channel-oriented security. TLS 106 standardizes SSL and may be used with any connection-oriented 107 service. TLS provides mechanisms for both one- and two-way 108 authentication, dynamic session keying, and data stream privacy and 109 integrity. 111 This document describes how to use COPS over TLS. "COPS over TLS" is 112 abbreviated COPS/TLS. 114 2 COPS Over TLS 116 COPS/TLS is very simple: use COPS over TLS similar to how you would 117 use COPS over TCP (COPS/TCP). Apart from a specific procedure used 118 to initialize the connection, there is no difference between 119 COPS/TLS and COPS/TCP. 121 3 Separate Ports versus Upward Negotiation 123 There are two ways in which insecure and secure versions of the same 124 protocol can be run simultaneously. 126 In the first method, the secure version of the protocol is also 127 allocated a well-known port. This strategy of having well-known port 128 numbers for both, the secure and insecure versions, is known as 129 'Separate Ports'. The clients requiring security can simply connect 130 to the well-known secure port. This method is easy to implement, 131 with no modifications needed to existing insecure implementations. 132 The disadvantage, however, is that it doesn't scale well, with a new 133 port required for each secure implementation. More problems with 134 this approach have been listed in [RFC2595]. 136 The second method is known as 'Upward Negotiation'. In this method, 137 the secure and insecure versions of the protocol run on the same 138 port. The client connects to the server, both discover each others' 139 capabilities, and start security negotiations if desired. This 140 method usually requires some changes to the protocol being secured. 142 COPS/TLS uses the Upward Negotiation method to secure COPS messages. 144 4 COPS/TLS Objects and Error codes 146 This section describes the COPS objects and error codes needed to 147 support COPS/TLS. 149 4.1 The Security ClientSI Object 151 The Security ClientSI object is used by the PDP and the PEP to start 152 the TLS negotiation. This object should be included only in the 153 Client-Open or Client-Accept messages. It MUST NOT be included in 154 any other COPS message. 156 0 1 2 3 157 +----------+----------+----------+----------+ 158 | Length (Octets) | C-Num=9 | C-Type=2 | 159 +----------+----------+----------+----------+ 160 | //////// | Flags | 161 +----------+----------+----------+----------+ 162 Note: //// implies the field is reserved, set to 0 and should be 163 ignored on receipt. 165 Flags: 16 bits 166 0x01 = StartTLS 167 This flag indicates that the sender of the message wishes to 168 initiate a TLS handshake. 170 The Client-Type of any message containing this Named ClientSI object 171 MUST be 0. Client-Type 0 is used to negotiate COPS connection level 172 security and must only be used during the connection establishment 173 phase. Please refer to section 4.1 of [RFC2748] for more details. 175 4.2 Error Codes 177 This section adds to the error codes described in section 2.2.8 178 (Error Object) of [RFC2748]. 180 Error Code: error-code-TBD-by-IANA = TLS Required 182 This error code should be used by either PEP or PDP to indicate a 183 security-related connection closure. 185 5 COPS/TLS Secure Connection Initiation 186 Security negotiation may be initiated either by the PDP or the PEP. 187 The PEP can initiate a negotiation via a Client-Open message, while 188 a PDP can initiate a negotiation via a Client-Accept message. 190 Once the TLS connection is established, all COPS data MUST be sent 191 as TLS "application data". 193 5.1 PEP Initiated Security Negotiation 195 A PEP MAY initiate security negotiation with a PDP using the Client- 196 Open message. The Client-Open message MUST have a Client-Type of 0 197 and MUST include the Security ClientSI object. 199 Upon receiving the Client-Open message, the PDP SHOULD respond with 200 a Client-Accept message containing the Security ClientSI object. 202 Note that in order to carry the Security ClientSI object, the 203 contents of the Client-Accept message defined in section 3.7 of 204 [RFC2748] need to change to the following: 206 ::= 207 208 [] 209 [] 210 [] 212 Upon receiving the appropriate Client-Accept message, the PEP SHOULD 213 initiate the TLS handshake. 215 The message exchange is as follows: 216 C: Client-Open (Client-Type = 0, Security) 217 S: Client-Accept (Client-Type = 0, Security) 218 219 C/S: <...further messages...> 221 Instead of sending a Client-Accept message, the PDP may choose to 222 close the connection if it does not wish to open a secure connection 223 with the PEP. It MUST include the error code error-code-TBD-by-IANA 224 in the ensuing Client-Close message. 226 A PEP expecting the Security ClientSI object in a Client-Accept 227 message MUST close the connection if the ClientSI object is missing. 228 It MUST include the error code error-code-TBD-by-IANA in the ensuing 229 Client-Close message. 231 5.2 PDP Initiated Security Negotiation 233 The PEP initially opens a TCP connection with the PDP on the 234 standard COPS port and sends a Client-Open message. This Client-Open 235 message MUST have a Client-Type of 0. 237 The PDP SHOULD then reply with a Client-Accept message. In order to 238 signal the PEP to start the TLS handshake, the PDP MUST include the 239 Security ClientSI object in the Client-Accept message. 241 Upon receiving the Client-Accept message with the Security ClientSI 242 object, the PEP SHOULD initiate the TLS handshake. If for any reason 243 the PEP cannot initiate the handshake, it MUST close the connection. 245 The message exchange is as follows: 246 C: Client-Open (Client-Type = 0) 247 S: Client-Accept (Client-Type = 0, Security) 248 249 C/S: <...further messages...> 251 Before completion of the TLS handshake, the PEP MUST NOT send any 252 messages other than Client-Close and Keep-Alive. Upon receiving any 253 other message, a PDP expecting a TLS negotiation MUST issue a 254 Client-Close message with an error code of error-code-TBD-by-IANA. 256 A PDP wishing to negotiate security with a PEP having a non-secure 257 connection MUST send a Client-Close with the error code error-code- 258 TBD-by-IANA and wait for the PEP to reconnect. Upon receiving the 259 Client-Open message, it SHOULD use the Client-Accept message to 260 initiate security negotiation. 262 6 Connection Closure 264 TLS provides facilities to securely close its connections. Reception 265 of a valid closure alert assures an implementation that no further 266 data will arrive on that connection. The TLS specification requires 267 TLS implementations to initiate a closure alert exchange before 268 closing a connection. It also permits TLS implementations to close 269 connections without waiting to receive closure alerts from the peer, 270 provided they send their own first. A connection closed in this way 271 is known as an "incomplete close". TLS allows implementations to 272 reuse the session in this case, but COPS/TLS makes no use of this 273 capability. 275 A connection closed without first sending a closure alert is known 276 as a "premature close". Note that a premature close does not call 277 into question the security of the data already received, but simply 278 indicates that subsequent data might have been truncated. Because 279 TLS is oblivious to COPS message boundaries, it is necessary to 280 examine the COPS data itself (specifically the Message header) to 281 determine whether truncation occurred. 283 6.1 PEP System Behavior 285 PEP implementations MUST treat premature closes as errors and any 286 data received as potentially truncated. The COPS protocol allows the 287 PEP system to find out whether truncation took place. A PEP system 288 detecting an incomplete close SHOULD recover gracefully. 290 PEP systems MUST send a closure alert before closing the connection. 291 PEPs unprepared to receive any more data MAY choose not to wait for 292 the PDP system's closure alert and simply close the connection, thus 293 generating an incomplete close on the PDP side. 295 6.2 PDP System Behavior 297 COPS permits a PEP to close the connection at any time, and requires 298 PDPs to recover gracefully. In particular, PDPs SHOULD be prepared 299 to receive an incomplete close from the PEP, since a PEP often shuts 300 down for operational reasons unrelated to the transfer of policy 301 information between the PEP and PDP. 303 Implementation note: The PDP ordinarily expects to be able to 304 signal end of data by closing the connection. However, the PEP 305 may have already sent the closure alert and dropped the 306 connection. 308 PDP systems MUST attempt to initiate an exchange of closure alerts 309 with the PEP system before closing the connection. PDP systems MAY 310 close the connection after sending the closure alert, thus 311 generating an incomplete close on the PEP side. 313 7 Endpoint Identification and Access Control 315 All PEP implementations of COPS/TLS MUST support an access control 316 mechanism to identify authorized PDPs. This requirement provides a 317 level of assurance that the policy arriving at the PEP is actually 318 valid. PEP deployments SHOULD require the use of this access control 319 mechanism for operation of COPS over TLS. When access control is 320 enabled, the PEP implementation MUST NOT initiate COPS/TLS 321 connections to systems not authorized as PDPs by the access control 322 mechanism. 324 Similarly, PDP COPS/TLS implementations MUST support an access 325 control mechanism permitting them to restrict their services to 326 authorized PEP systems only. However, deployments MAY choose not to 327 use an access control mechanism at the PDP, as organizations might 328 not consider the types of policy being deployed as sensitive, and 329 therefore do not need to incur the expense of managing credentials 330 for the PEP systems. If access controls are used, however, the PDP 331 implementation MUST terminate COPS/TLS connections from unauthorized 332 PEP systems and log an error if an auditable logging mechanism is 333 present. 335 Implementations of COPS/TLS MUST use X.509 v3 certificates 336 conforming to [RFC3280] to identify PDP and PEP systems. COPS/TLS 337 systems MUST perform certificate verification processing conforming 338 to [RFC3280]. 340 If a subjectAltName extension of type dNSName or iPAddress is 341 present in the PDP's certificate, it MUST be used as the PDP 342 identity. If both types are present, dNSName SHOULD be used as the 343 PDP identity. If neither of the types is present, the most specific 344 Common Name field in the Subject field of the certificate SHOULD be 345 used. 347 Matching is performed using the matching rules specified by 348 [RFC3280]. If more than one identity of a given type is present in 349 the certificate (e.g. more than one dNSName name in the 350 subjectAltName certificate extension), a match in any one of the 351 provided identities is acceptable. Generally, the COPS system uses 352 the first name for matching, except as noted below in the IP 353 address checking requirements. 355 7.1 PDP Identity 357 Generally, COPS/TLS requests are generated by the PEP consulting 358 bootstrap policy information that identifies PDPs that the PEP is 359 authorized to connect to. This policy provides the PEP with the 360 hostname or IP address of the PDP. How this bootstrap policy 361 information arrives at the PEP is outside the scope of this 362 document. However, all PEP implementations MUST provide a mechanism 363 to securely deliver or configure the bootstrap policy. 365 All PEP implementations MUST be able to securely acquire the signing 366 certificates of authorized Certificate Authorities that issue PDP 367 certificates. Also, the PEPs MUST support a mechanism to securely 368 acquire an access control list or filter identifying the CA's set of 369 authorized PDPs. 371 PEP deployments that participate in multiple domains, such as those 372 on mobile platforms, MAY use different CAs and access control lists 373 in each domain. 375 If the PDP hostname or IP address is available via the bootstrap 376 policy, the PEP MUST check it against the PDP's identity as 377 presented in the PDP's TLS Certificate message. 379 In some cases the bootstrap policy will identify the authorized PDP 380 only by an IP address of the PDP system. In this case, the 381 subjectAltName MUST be present in the certificate, and it MUST 382 include an iPAdress format matching the expected name of the policy 383 server. 385 If the hostname of the PDP does not match the identity in the 386 certificate, a PEP on a user oriented system MUST either notify the 387 user (PEP systems MAY afford the user the opportunity to continue 388 with the connection in any case) or terminate the connection with a 389 bad certificate error. PEPs on unattended systems MUST log the error 390 to an appropriate audit log (if available) and MUST terminate the 391 connection with a bad certificate error. Unattended PEP systems MAY 392 provide a configuration setting that disables this check, but then 393 MUST provide a setting which enables it. 395 7.2 PEP Identity 396 When PEP systems are not access controlled, the PDP need have no 397 external knowledge of what the PEP's identity ought to be and so 398 checks are neither possible nor necessary. In this case, there is no 399 requirement for PEP systems to register with a certificate 400 authority, and COPS over TLS uses one-way authentication, of the PDP 401 to the PEP. 403 When PEP systems are access controlled, PEPs MUST be PKI clients in 404 the sense of [RFC3280]. In this case, COPS over TLS uses two-way 405 authentication, and the PDP MUST perform the same identity checks 406 for the PEPs as described above for the PDP. 408 When access controls are in effect at the PDP, PDP implementations 409 MUST have a mechanism to securely acquire the signing certificates 410 of the Certificate Authorities issuing certificates to any of the 411 PEPs they support. 413 8 Backward Compatibility 415 The PEP and PDP SHOULD be backward compatible with peers that have 416 not been modified to support COPS/TLS. They SHOULD handle errors 417 generated in response to the Security ClientSI object. 419 9 IANA Considerations 421 The IANA shall add the following Error-Code to the cops-parameters 422 registry located at http://www.iana.org/assignments/cops-parameters. 424 Error-Code: error-code-TBD-by-IANA 425 Description: TLS Required 427 For the Named ClientSI object for Client-Type 0, the IANA shall add 428 the following Flags value: 429 0x01 = StartTLS 431 Further values for the Flags field and the reserved field can only 432 be assigned by IETF Consensus rule as defined in [RFC2434]. 434 10 Security Considerations 436 A COPS PDP and PEP MUST check the results of the TLS negotiation to 437 see whether an acceptable degree of authentication and privacy have 438 been achieved. If the negotiation has resulted in unacceptable 439 algorithms or key lengths, either side MAY choose to terminate the 440 connection. 442 A man-in-the-middle attack can be launched by deleting the Security 443 ClientSI object from the Client-Open or Client-Accept messages. To 444 prevent this, the PEP and PDP MUST use the Integrity object as 445 defined in [RFC2748]. 447 11 References 448 11.1 Normative References 450 [RFC2026] Bradner, S., "The Internet Standards Process - Revision 451 3", RFC 2026, October 1996 453 [RFC2119] Bradner, S., "Key Words for use in RFCs to indicate 454 Requirement Levels", RFC 2119, March 1997. 456 [RFC2748] Durham, D., Boyle, J., Cohen, R., Herzog, R., Rajan, 457 R., Sastry, A., "The COPS (Common Open Policy Service) Protocol", 458 RFC 2748, January 2000. 460 [RFC3280] Housley, R., Ford, W., Polk, W., Solo, D., "Internet 461 X.509 Public Key Infrastructure Certificate and Certificate 462 Revocation List (CRL) Profile ", RFC 3280, April 2002. 464 [RFC2246] Dierks, T., Allen, C., "The TLS Protocol", RFC 2246, 465 January 1999. 467 11.2 Informative References 469 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 471 [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 472 2595, June 1999. 474 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP 475 over Transport Layer Security", RFC 3207, February 2002. 477 [RFC2434] Alvestrand, H., Narten, T., "Guidelines for writing an 478 IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 479 1998. 481 12 Author Addresses 483 Jesse R. Walker 484 Intel Corporation 485 2111 N.E. 25th Avenue 486 Hillsboro, OR 97214 487 USA 488 jesse[dot]walker[at]intel[dot]com 490 Amol Kulkarni 491 Intel Corporation 492 JF3-206 493 2111 N.E. 25th Avenue 494 Hillsboro, OR 97214 495 USA 496 amol[dot]kulkarni[at]intel[dot]com 498 13 IPR Disclosure Acknowledgement 499 By submitting this Internet-Draft, we certify that any applicable 500 patent or other IPR claims of which we are aware have been 501 disclosed, and any of which we become aware will be disclosed, in 502 accordance with RFC 3668. 504 14 Disclaimer of Validity 506 The IETF takes no position regarding the validity or scope of any 507 Intellectual Property Rights or other rights that might be claimed 508 to pertain to the implementation or use of the technology described 509 in this document or the extent to which any license under such 510 rights might or might not be available; nor does it represent that 511 it has made any independent effort to identify any such rights. 512 Information on the procedures with respect to rights in RFC 513 documents can be found in BCP 78 and BCP 79. 515 Copies of IPR disclosures made to the IETF Secretariat and any 516 assurances of licenses to be made available, or the result of an 517 attempt made to obtain a general license or permission for the use 518 of such proprietary rights by implementers or users of this 519 specification can be obtained from the IETF on-line IPR repository 520 at http://www.ietf.org/ipr. 522 The IETF invites any interested party to bring to its attention any 523 copyrights, patents or patent applications, or other proprietary 524 rights that may cover technology that may be required to implement 525 this standard. Please address the information to the IETF at ietf- 526 ipr@ietf.org. 528 15 Copyright Statement 530 Copyright (C) The Internet Society (2004). This document is subject 531 to the rights, licenses and restrictions contained in BCP 78, and 532 except as set forth therein, the authors retain all their rights. 534 16 Disclaimer 536 This document and the information contained herein are provided on 537 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 538 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 539 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 540 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 541 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 542 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 544 17 Acknowledgements 546 This document freely plagiarizes and adapts Eric Rescorla's similar 547 document [RFC2818] that specifies how HTTP runs over TLS. 548 Discussions with David Durham, Scott Hahn and Ylian Sainte-Hillaire 549 also lead to improvements in this document. 551 The authors wish to thank Uri Blumenthal for doing a thorough 552 security review of the document. 554 Funding for the RFC Editor function is currently provided by the 555 Internet Society.