idnits 2.17.1 draft-ietf-rap-cops-tls-10.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 526. -- Found old boilerplate from RFC 3978, Section 5.5 on line 565. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 537. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 544. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 550. ** 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 (December 1, 2004) is 7057 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 17, but not defined ** Obsolete undefined reference: RFC 3667 (Obsoleted by RFC 3978) == Missing Reference: 'RFC2753' is mentioned on line 89, but not defined == Unused Reference: 'RFC2026' is defined on line 474, but no explicit reference was found in the text == Unused Reference: 'RFC3207' is defined on line 498, 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. -------------------------------------------------------------------------------- 1 Internet Draft Jesse Walker 2 Expiration: June 2005 Amol Kulkarni, Ed. 3 File: draft-ietf-rap-cops-tls-10.txt Intel Corp. 5 COPS Over TLS 7 Last Updated: December 1, 2004 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of section 3 of RFC 3667 [RFC3667]. By submitting this Internet- 13 Draft, each author represents that any applicable patent or other 14 IPR claims of which he or she is aware have been or will be 15 disclosed, and any of which he or she become aware will be 16 disclosed, in accordance with RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is inappropriate to use Internet-Drafts 26 as reference material or to cite them other than as "work in 27 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 Conventions used in this document 37 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 38 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 39 this document are to be interpreted as described in RFC 2119 40 [RFC2119]. 42 Abstract 44 This document describes how to use Transport Layer Security (TLS) 45 to secure Common Open Policy Service (COPS) connections over the 46 Internet. 48 This document also updates RFC 2748 by modifying the contents of 49 the Client-Accept message. 51 Table Of Contents 53 Glossary..........................................................3 54 1 Introduction...................................................3 55 2 COPS Over TLS..................................................3 56 3 Separate Ports versus Upward Negotiation.......................3 57 4 COPS/TLS Objects and Error codes...............................4 58 4.1 The TLS Message Integrity Object (Integrity-TLS)..............4 59 4.2 Error Codes...................................................4 60 5 COPS/TLS Secure Connection Initiation..........................5 61 5.1 PEP Initiated Security Negotiation............................5 62 5.2 PDP Initiated Security Negotiation............................6 63 6 Connection Closure.............................................6 64 6.1 PEP System Behavior...........................................7 65 6.2 PDP System Behavior...........................................7 66 7 Endpoint Identification and Access Control.....................7 67 7.1 PDP Identity..................................................8 68 7.2 PEP Identity..................................................9 69 8 Backward Compatibility.........................................9 70 9 IANA Considerations.............................................9 71 10 Security Considerations.......................................10 72 11 References....................................................10 73 11.1 Normative References........................................10 74 11.2 Informative References......................................10 75 12 Author Addresses.............................................11 76 13 IPR Disclosure Acknowledgement...............................11 77 14 Disclaimer of Validity.......................................11 78 15 Copyright Statement..........................................11 79 16 Disclaimer...................................................12 80 17 Acknowledgements.............................................12 82 Glossary 83 COPS - Common Open Policy Service. See [RFC2748]. 84 COPS/TCP - A plain-vanilla implementation of COPS. 85 COPS/TLS - A secure implementation of COPS using TLS. 86 PDP - Policy Decision Point. Also referred to as the Policy 87 Server. See [RFC2753]. 88 PEP - Policy Enforcement Point. Also referred to as the Policy 89 Client. See [RFC2753]. 91 1 Introduction 93 COPS [RFC2748] was designed to distribute clear-text policy 94 information from a centralized Policy Decision Point (PDP) to a set 95 of Policy Enforcement Points (PEP) in the Internet. COPS provides 96 its own security mechanisms to protect the per-hop integrity of the 97 deployed policy. However, the use of COPS for sensitive applications 98 such as some types of security policy distribution requires 99 additional security measures, such as data confidentiality. This is 100 because some organizations find it necessary to hide some or all of 101 their security policies, e.g., because policy distribution to 102 devices such as mobile platforms can cross domain boundaries. 104 TLS [RFC2246] was designed to provide channel-oriented security. TLS 105 standardizes SSL and may be used with any connection-oriented 106 service. TLS provides mechanisms for both one- and two-way 107 authentication, dynamic session keying, and data stream privacy and 108 integrity. 110 This document describes how to use COPS over TLS. "COPS over TLS" is 111 abbreviated COPS/TLS. 113 2 COPS Over TLS 115 COPS/TLS is very simple: use COPS over TLS similar to how you would 116 use COPS over TCP (COPS/TCP). Apart from a specific procedure used 117 to initialize the connection, there is no difference between 118 COPS/TLS and COPS/TCP. 120 3 Separate Ports versus Upward Negotiation 122 There are two ways in which insecure and secure versions of the same 123 protocol can be run simultaneously. 125 In the first method, the secure version of the protocol is also 126 allocated a well-known port. This strategy of having well-known port 127 numbers for both, the secure and insecure versions, is known as 128 'Separate Ports'. The clients requiring security can simply connect 129 to the well-known secure port. This method is easy to implement, 130 with no modifications needed to existing insecure implementations. 131 The disadvantage, however, is that it doesn't scale well, with a new 132 port required for each secure implementation. More problems with 133 this approach have been listed in [RFC2595]. 135 The second method is known as 'Upward Negotiation'. In this method, 136 the secure and insecure versions of the protocol run on the same 137 port. The client connects to the server, both discover each others' 138 capabilities, and start security negotiations if desired. This 139 method usually requires some changes to the protocol being secured. 141 COPS/TLS uses the Upward Negotiation method to secure COPS messages. 143 4 COPS/TLS Objects and Error codes 145 This section describes the COPS objects and error codes needed to 146 support COPS/TLS. 148 4.1 The TLS Message Integrity Object (Integrity-TLS) 150 The TLS Integrity object is used by the PDP and the PEP to start the 151 TLS negotiation. This object should be included only in the Client- 152 Open or Client-Accept messages. It MUST NOT be included in any other 153 COPS message. 155 0 1 2 3 157 +----------+----------+----------+----------+ 158 | Length (Octets) | C-Num=16 | C-Type=2 | 159 +----------+----------+----------+----------+ 160 | //////// | Flags | 161 +----------+----------+----------+----------+ 163 Note: //// implies the field is reserved, set to 0 and should be 164 ignored on receipt. 166 Flags: 16 bits 167 0x01 = StartTLS 168 This flag indicates that the sender of the message 169 wishes to initiate a TLS handshake. 171 The Client-Type of any message containing this object MUST be 0. 172 Client-Type 0 is used to negotiate COPS connection level security 173 and must only be used during the connection establishment phase. 174 Please refer to section 4.1 of [RFC2748] for more details. 176 4.2 Error Codes 178 This section uses the error codes described in section 2.2.8 (Error 179 Object) of [RFC2748]. 181 Error Code: 13= Unknown COPS Object: 183 Sub-code (octet 2) contains the unknown object's C-Num and (octet 3) 184 contains unknown object's C-Type. If the PEP or PDP does not support 185 TLS, the C-Num specified will be 16 and the C-Type will be 2. This 186 demonstrates that the TLS version of the Integrity object not known. 188 This error code should be used by either PEP or PDP to indicate a 189 security-related connection closure if it cannot support a TLS 190 connection for the COPS protocol. 192 If the PDP wishes to negotiate a different security mechanism than 193 requested by the PEP in the Client-Open, it should send the 194 following error code: 196 Error Code: 15= Authentication Required 198 Where the Sub-code (octet 2) contains the C-Num=16 value for the 199 Integrity Object and (octet 3) will specify the PDP 200 required/preferred Integrity object C-Type. If the server does not 201 support any form of COPS-Security, it will set the Sub-code (octet 202 2) to 16 and (octet 3) to zero instead, signifying that no type of 203 the Integrity object is supported. 205 5 COPS/TLS Secure Connection Initiation 207 Security negotiation may be initiated either by the PDP or the PEP. 208 The PEP can initiate a negotiation via a Client-Open message, while 209 a PDP can initiate a negotiation via a Client-Accept message. 211 Once the TLS connection is established, all COPS data MUST be sent 212 as TLS "application data". 214 5.1 PEP Initiated Security Negotiation 216 A PEP MAY initiate a TLS security negotiation with a PDP using the 217 Client-Open message. To do this, the Client-Open message MUST have a 218 Client-Type of 0 and MUST include the Integrity-TLS object. 220 Upon receiving the Client-Open message, the PDP SHOULD respond with 221 a Client-Accept message containing the Integrity-TLS object. 223 Note that in order to carry the Integrity-TLS object, the contents 224 of the Client-Accept message defined in section 3.7 of [RFC2748] 225 need not change, other than the C-Type of the integrity object 226 contained there-in should now be C-Type=2. For Example: 228 ::= 229 230 [] 231 [] 233 Upon receiving the appropriate Client-Accept message, the PEP SHOULD 234 initiate the TLS handshake. 236 The message exchange is as follows: 237 C: Client-Open (Client-Type = 0, Integrity-TLS) 238 S: Client-Accept (Client-Type = 0, Integrity-TLS) 239 240 C/S: <...further messages...> 242 In case the PDP does not wish to open a secure connection with the 243 PEP, it MUST reply with a Client-Close message and close the 244 connection. The Client-Close message MUST include the error code 245 15=Authentication required, with the Sub-code (octet 2) set to 16 246 for the Integrity object's C-Num and (octet 3) set to the C-Type 247 corresponding to the server's preferred Integrity type or zero for 248 no security. 250 A PEP requiring the Integrity-TLS object in a Client-Accept message 251 MUST close the connection if the Integrity-TLS object is missing. It 252 MUST include the error code 15= Authentication required, with the 253 Sub-code (octet 2) containing the required Integrity object's C- 254 Num=16 and (octet 3) containing the required Integrity object's C- 255 Type=2, in the ensuing Client-Close message. 257 5.2 PDP Initiated Security Negotiation 259 The PEP initially opens a TCP connection with the PDP on the 260 standard COPS port and sends a Client-Open message. This Client-Open 261 message MUST have a Client-Type of 0. 263 The PDP SHOULD then reply with a Client-Accept message. In order to 264 signal the PEP to start the TLS handshake, the PDP MUST include the 265 Integrity-TLS object in the Client-Accept message. 267 Upon receiving the Client-Accept message with the Integrity-TLS 268 object, the PEP SHOULD initiate the TLS handshake. If for any reason 269 the PEP cannot initiate the handshake, it MUST close the connection. 271 The message exchange is as follows: 272 C: Client-Open (Client-Type = 0) 273 S: Client-Accept (Client-Type = 0, Integrity-TLS) 274 275 C/S: <...further messages...> 277 After receiving the Client-Accept, the PEP MUST NOT send any 278 messages until the TLS handshake is complete. Upon receiving any 279 message from the PEP before the TLS handshake starts, the PDP MUST 280 issue a Client-Close message with an error code 15= Authentication 281 Required. 283 A PDP wishing to negotiate security with a PEP having an existing 284 non-secure connection MUST send a Client-Close with the error code 285 15= Authentication required, with the Sub-code (octet 2) containing 286 the required Integrity object's C-Num=16 and (octet 3) containing 287 the required Integrity object's C-Type=2 and wait for the PEP to 288 reconnect. Upon receiving the Client-Open message, it SHOULD use the 289 Client-Accept message to initiate security negotiation. 291 6 Connection Closure 292 TLS provides facilities to securely close its connections. Reception 293 of a valid closure alert assures an implementation that no further 294 data will arrive on that connection. The TLS specification requires 295 TLS implementations to initiate a closure alert exchange before 296 closing a connection. It also permits TLS implementations to close 297 connections without waiting to receive closure alerts from the peer, 298 provided they send their own first. A connection closed in this way 299 is known as an "incomplete close". TLS allows implementations to 300 reuse the session in this case, but COPS/TLS makes no use of this 301 capability. 303 A connection closed without first sending a closure alert is known 304 as a "premature close". Note that a premature close does not call 305 into question the security of the data already received, but simply 306 indicates that subsequent data might have been truncated. Because 307 TLS is oblivious to COPS message boundaries, it is necessary to 308 examine the COPS data itself (specifically the Message header) to 309 determine whether truncation occurred. 311 6.1 PEP System Behavior 313 PEP implementations MUST treat premature closes as errors and any 314 data received as potentially truncated. The COPS protocol allows the 315 PEP system to find out whether truncation took place. A PEP system 316 detecting an incomplete close SHOULD recover gracefully. 318 PEP systems MUST send a closure alert before closing the connection. 319 PEPs unprepared to receive any more data MAY choose not to wait for 320 the PDP system's closure alert and simply close the connection, thus 321 generating an incomplete close on the PDP side. 323 6.2 PDP System Behavior 325 COPS permits a PEP to close the connection at any time, and requires 326 PDPs to recover gracefully. In particular, PDPs SHOULD be prepared 327 to receive an incomplete close from the PEP, since a PEP often shuts 328 down for operational reasons unrelated to the transfer of policy 329 information between the PEP and PDP. 331 Implementation note: The PDP ordinarily expects to be able to 332 signal end of data by closing the connection. However, the PEP 333 may have already sent the closure alert and dropped the 334 connection. 336 PDP systems MUST attempt to initiate an exchange of closure alerts 337 with the PEP system before closing the connection. PDP systems MAY 338 close the connection after sending the closure alert, thus 339 generating an incomplete close on the PEP side. 341 7 Endpoint Identification and Access Control 343 All PEP implementations of COPS/TLS MUST support an access control 344 mechanism to identify authorized PDPs. This requirement provides a 345 level of assurance that the policy arriving at the PEP is actually 346 valid. PEP deployments SHOULD require the use of this access control 347 mechanism for operation of COPS over TLS. When access control is 348 enabled, the PEP implementation MUST NOT initiate COPS/TLS 349 connections to systems not authorized as PDPs by the access control 350 mechanism. 352 Similarly, PDP COPS/TLS implementations MUST support an access 353 control mechanism permitting them to restrict their services to 354 authorized PEP systems only. However, deployments MAY choose not to 355 use an access control mechanism at the PDP, as organizations might 356 not consider the types of policy being deployed as sensitive, and 357 therefore do not need to incur the expense of managing credentials 358 for the PEP systems. If access controls are used, however, the PDP 359 implementation MUST terminate COPS/TLS connections from unauthorized 360 PEP systems and log an error if an auditable logging mechanism is 361 present. 363 Implementations of COPS/TLS MUST use X.509 v3 certificates 364 conforming to [RFC3280] to identify PDP and PEP systems. COPS/TLS 365 systems MUST perform certificate verification processing conforming 366 to [RFC3280]. 368 If a subjectAltName extension of type dNSName or iPAddress is 369 present in the PDP's certificate, it MUST be used as the PDP 370 identity. If both types are present, dNSName SHOULD be used as the 371 PDP identity. If neither of the types is present, the most specific 372 Common Name field in the Subject field of the certificate SHOULD be 373 used. 375 Matching is performed using the matching rules specified by 376 [RFC3280]. If more than one identity of a given type is present in 377 the certificate (e.g. more than one dNSName name in the 378 subjectAltName certificate extension), a match in any one of the 379 provided identities is acceptable. Generally, the COPS system uses 380 the first name for matching, except as noted below in the IP 381 address checking requirements. 383 7.1 PDP Identity 385 Generally, COPS/TLS requests are generated by the PEP consulting 386 bootstrap policy information that identifies PDPs that the PEP is 387 authorized to connect to. This policy provides the PEP with the 388 hostname or IP address of the PDP. How this bootstrap policy 389 information arrives at the PEP is outside the scope of this 390 document. However, all PEP implementations MUST provide a mechanism 391 to securely deliver or configure the bootstrap policy. 393 All PEP implementations MUST be able to securely acquire the trust 394 anchor for each authorized Certification Authority (CA) that issues 395 PDP certificates. Also, the PEPs MUST support a mechanism to 396 securely acquire an access control list or filter identifying the 397 set of authorized PDPs associated with each CA. 399 PEP deployments that participate in multiple domains, such as those 400 on mobile platforms, MAY use different CAs and access control lists 401 in each domain. 403 If the PDP hostname or IP address is available via the bootstrap 404 policy, the PEP MUST check it against the PDP's identity as 405 presented in the PDP's TLS Certificate message. 407 In some cases the bootstrap policy will identify the authorized PDP 408 only by an IP address of the PDP system. In this case, the 409 subjectAltName MUST be present in the certificate, and it MUST 410 include an iPAdress format matching the expected name of the policy 411 server. 413 If the hostname of the PDP does not match the identity in the 414 certificate, a PEP on a user oriented system MUST either notify the 415 user (PEP systems MAY afford the user the opportunity to continue 416 with the connection in any case) or terminate the connection with a 417 bad certificate error. PEPs on unattended systems MUST log the error 418 to an appropriate audit log (if available) and MUST terminate the 419 connection with a bad certificate error. Unattended PEP systems MAY 420 provide a configuration setting that disables this check, but then 421 MUST provide a setting which enables it. 423 7.2 PEP Identity 425 When PEP systems are not access controlled, the PDP need have no 426 external knowledge of what the PEP's identity ought to be and so 427 checks are neither possible nor necessary. In this case, there is no 428 requirement for PEP systems to register with a certificate 429 authority, and COPS over TLS uses one-way authentication, of the PDP 430 to the PEP. 432 When PEP systems are access controlled, PEPs MUST be the subjects 433 of end entity certificates [RFC3280]. In this case, COPS over TLS 434 uses two-way authentication, and the PDP MUST perform the same 435 identity checks for the PEPs as described above for the PDP. 437 When access controls are in effect at the PDP, PDP implementations 438 MUST have a mechanism to securely acquire the trust anchor for each 439 authorized Certification Authority (CA) that issues certificates to 440 supported PEPs. 442 8 Backward Compatibility 444 The PEP and PDP SHOULD be backward compatible with peers that have 445 not been modified to support COPS/TLS. They SHOULD handle errors 446 generated in response to the Integrity-TLS object. 448 9 IANA Considerations 449 For the Integrity-TLS object for Client-Type 0, the IANA shall add 450 the following Flags value: 451 0x01 = StartTLS 453 Further values for the Flags field and the reserved field can only 454 be assigned by IETF Consensus rule as defined in [RFC2434]. 456 10 Security Considerations 458 A COPS PDP and PEP MUST check the results of the TLS negotiation to 459 see whether an acceptable degree of authentication and privacy have 460 been achieved. If the negotiation has resulted in unacceptable 461 algorithms or key lengths, either side MAY choose to terminate the 462 connection. 464 A man-in-the-middle attack can be launched by deleting the 465 Integrity-TLS object or altering the Client-Open or Client-Accept 466 messages. If security is required, the PEP and PDP bootstrap policy 467 must specify this, and PEP and PDP implementations should reject 468 Client-Open or Client-Accept messages that fail to include an 469 Integrity-TLS object. 471 11 References 472 11.1 Normative References 474 [RFC2026] Bradner, S., "The Internet Standards Process - Revision 475 3", RFC 2026, October 1996 477 [RFC2119] Bradner, S., "Key Words for use in RFCs to indicate 478 Requirement Levels", RFC 2119, March 1997. 480 [RFC2748] Durham, D., Boyle, J., Cohen, R., Herzog, R., Rajan, 481 R., Sastry, A., "The COPS (Common Open Policy Service) Protocol", 482 RFC 2748, January 2000. 484 [RFC3280] Housley, R., Ford, W., Polk, W., Solo, D., "Internet 485 X.509 Public Key Infrastructure Certificate and Certificate 486 Revocation List (CRL) Profile ", RFC 3280, April 2002. 488 [RFC2246] Dierks, T., Allen, C., "The TLS Protocol", RFC 2246, 489 January 1999. 491 11.2 Informative References 493 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 495 [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 496 2595, June 1999. 498 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP 499 over Transport Layer Security", RFC 3207, February 2002. 501 [RFC2434] Alvestrand, H., Narten, T., "Guidelines for writing an 502 IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 503 1998. 505 12 Author Addresses 507 Amol Kulkarni 508 Intel Corporation 509 2111 N.E. 25th Avenue 510 Hillsboro, OR 97214 511 USA 512 amol[dot]kulkarni[at]intel[dot]com 514 Jesse R. Walker 515 Intel Corporation 516 2111 N.E. 25th Avenue 517 Hillsboro, OR 97214 518 USA 519 jesse[dot]walker[at]intel[dot]com 521 13 IPR Disclosure Acknowledgement 523 By submitting this Internet-Draft, we certify that any applicable 524 patent or other IPR claims of which we are aware have been 525 disclosed, and any of which we become aware will be disclosed, in 526 accordance with RFC 3668. 528 14 Disclaimer of Validity 530 The IETF takes no position regarding the validity or scope of any 531 Intellectual Property Rights or other rights that might be claimed 532 to pertain to the implementation or use of the technology described 533 in this document or the extent to which any license under such 534 rights might or might not be available; nor does it represent that 535 it has made any independent effort to identify any such rights. 536 Information on the procedures with respect to rights in RFC 537 documents can be found in BCP 78 and BCP 79. 539 Copies of IPR disclosures made to the IETF Secretariat and any 540 assurances of licenses to be made available, or the result of an 541 attempt made to obtain a general license or permission for the use 542 of such proprietary rights by implementers or users of this 543 specification can be obtained from the IETF on-line IPR repository 544 at http://www.ietf.org/ipr. 546 The IETF invites any interested party to bring to its attention any 547 copyrights, patents or patent applications, or other proprietary 548 rights that may cover technology that may be required to implement 549 this standard. Please address the information to the IETF at ietf- 550 ipr@ietf.org. 552 15 Copyright Statement 553 Copyright (C) The Internet Society (2004). This document is subject 554 to the rights, licenses and restrictions contained in BCP 78, and 555 except as set forth therein, the authors retain all their rights. 557 16 Disclaimer 559 This document and the information contained herein are provided on 560 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 561 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 562 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 563 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 564 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 565 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 567 17 Acknowledgements 569 This document freely plagiarizes and adapts Eric Rescorla's similar 570 document [RFC2818] that specifies how HTTP runs over TLS. 571 Discussions with David Durham, Scott Hahn and Ylian Sainte-Hillaire 572 also lead to improvements in this document. 573 The authors wish to thank Uri Blumenthal for doing a thorough 574 security review of the document. 576 Funding for the RFC Editor function is currently provided by the 577 Internet Society.