idnits 2.17.1 draft-ietf-rap-cops-tls-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 550. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 590. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 561. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 568. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 574. ** 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: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. 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. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 (February 5, 2004) is 7376 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: 'RFCxxxx' is mentioned on line 460, but not defined ** Downref: Normative reference to an Informational RFC: RFC 2753 ** 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 (~~), 4 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Jesse Walker 2 Expiration: August 2005 Amol Kulkarni, Ed. 3 File: draft-ietf-rap-cops-tls-11.txt Intel Corp. 5 COPS Over TLS 7 Last Updated: February 5, 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. By submitting this Internet-Draft, each 13 author represents that any applicable patent or other IPR claims of 14 which he or she is aware have been or will be disclosed, and any of 15 which he or she become aware will be disclosed, in accordance with 16 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.............................................7 64 6.1 PEP System Behavior...........................................7 65 6.2 PDP System Behavior...........................................7 66 7 Endpoint Identification and Access Control.....................8 67 7.1 PDP Identity..................................................8 68 7.2 PEP Identity..................................................9 69 8 Backward Compatibility.........................................9 70 9 IANA Considerations............................................10 71 10 Security Considerations.......................................10 72 11 References....................................................10 73 11.1 Normative References........................................10 74 11.2 Informative References......................................11 75 12 Author Addresses.............................................11 76 13 IPR Disclosure Acknowledgement...............................11 77 14 Disclaimer of Validity.......................................11 78 15 Copyright Statement..........................................12 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 In view of the many issues with the Separate Ports approach, the 142 authors have decided to use the Upward Negotiation method for 143 COPS/TLS. 145 4 COPS/TLS Objects and Error codes 147 This section describes the COPS objects and error codes needed to 148 support COPS/TLS. 150 4.1 The TLS Message Integrity Object (Integrity-TLS) 152 The TLS Integrity object is used by the PDP and the PEP to start the 153 TLS negotiation. This object should be included only in the Client- 154 Open or Client-Accept messages. It MUST NOT be included in any other 155 COPS message. 157 0 1 2 3 159 +----------+----------+----------+----------+ 160 | Length (Octets) | C-Num=16 | C-Type=2 | 161 +----------+----------+----------+----------+ 162 | //////// | Flags | 163 +----------+----------+----------+----------+ 165 Note: //// implies the field is reserved, set to 0 and should be 166 ignored on receipt. 168 Flags: 16 bits 169 0x01 = StartTLS 170 This flag indicates that the sender of the message 171 wishes to initiate a TLS handshake. 173 The Client-Type of any message containing this object MUST be 0. 174 Client-Type 0 is used to negotiate COPS connection level security 175 and must only be used during the connection establishment phase. 176 Please refer to section 4.1 of [RFC2748] for more details. 178 4.2 Error Codes 180 This section uses the error codes described in section 2.2.8 (Error 181 Object) of [RFC2748]. 183 Error Code: 13= Unknown COPS Object: 185 Sub-code (octet 2) contains the unknown object's C-Num and (octet 3) 186 contains unknown object's C-Type. If the PEP or PDP does not support 187 TLS, the C-Num specified will be 16 and the C-Type will be 2. This 188 demonstrates that the TLS version of the Integrity object not known. 190 This error code should be used by either PEP or PDP to indicate a 191 security-related connection closure if it cannot support a TLS 192 connection for the COPS protocol. 194 If the PDP wishes to negotiate a different security mechanism than 195 requested by the PEP in the Client-Open, it should send the 196 following error code: 198 Error Code: 15= Authentication Required 200 Where the Sub-code (octet 2) contains the C-Num=16 value for the 201 Integrity Object and (octet 3) will specify the PDP 202 required/preferred Integrity object C-Type. If the server does not 203 support any form of COPS-Security, it will set the Sub-code (octet 204 2) to 16 and (octet 3) to zero instead, signifying that no type of 205 the Integrity object is supported. 207 5 COPS/TLS Secure Connection Initiation 209 Security negotiation may be initiated either by the PDP or the PEP. 210 The PEP can initiate a negotiation via a Client-Open message, while 211 a PDP can initiate a negotiation via a Client-Accept message. 213 Once the TLS connection is established, all COPS data MUST be sent 214 as TLS "application data". 216 5.1 PEP Initiated Security Negotiation 218 A PEP MAY initiate a TLS security negotiation with a PDP using the 219 Client-Open message. To do this, the Client-Open message MUST have a 220 Client-Type of 0 and MUST include the Integrity-TLS object. 222 Upon receiving the Client-Open message, the PDP SHOULD respond with 223 a Client-Accept message containing the Integrity-TLS object. 225 Note that in order to carry the Integrity-TLS object, the contents 226 of the Client-Accept message defined in section 3.7 of [RFC2748] 227 need not change, other than the C-Type of the integrity object 228 contained there-in should now be C-Type=2. For Example: 230 ::= 231 232 [] 233 [] 235 Note also that this new format of the Client-Accept message does 236 not replace or obsolete the existing Client-Accept message format, 237 which can continue to be used for non-secure COPS session 238 negotiations. 240 Upon receiving the appropriate Client-Accept message, the PEP SHOULD 241 initiate the TLS handshake. 243 The message exchange is as follows: 244 C: Client-Open (Client-Type = 0, Integrity-TLS) 245 S: Client-Accept (Client-Type = 0, Integrity-TLS) 246 247 C/S: <...further messages...> 249 In case the PDP does not wish to open a secure connection with the 250 PEP, it MUST reply with a Client-Close message and close the 251 connection. The Client-Close message MUST include the error code 252 15=Authentication required, with the Sub-code (octet 2) set to 16 253 for the Integrity object's C-Num and (octet 3) set to the C-Type 254 corresponding to the server's preferred Integrity type or zero for 255 no security. 257 A PEP requiring the Integrity-TLS object in a Client-Accept message 258 MUST close the connection if the Integrity-TLS object is missing. It 259 MUST include the error code 15= Authentication required, with the 260 Sub-code (octet 2) containing the required Integrity object's C- 261 Num=16 and (octet 3) containing the required Integrity object's C- 262 Type=2, in the ensuing Client-Close message. 264 5.2 PDP Initiated Security Negotiation 266 The PEP initially opens a TCP connection with the PDP on the 267 standard COPS port and sends a Client-Open message. This Client-Open 268 message MUST have a Client-Type of 0. 270 The PDP SHOULD then reply with a Client-Accept message. In order to 271 signal the PEP to start the TLS handshake, the PDP MUST include the 272 Integrity-TLS object in the Client-Accept message. 274 Upon receiving the Client-Accept message with the Integrity-TLS 275 object, the PEP SHOULD initiate the TLS handshake. If for any reason 276 the PEP cannot initiate the handshake, it MUST close the connection. 278 The message exchange is as follows: 279 C: Client-Open (Client-Type = 0) 280 S: Client-Accept (Client-Type = 0, Integrity-TLS) 281 282 C/S: <...further messages...> 284 After receiving the Client-Accept, the PEP MUST NOT send any 285 messages until the TLS handshake is complete. Upon receiving any 286 message from the PEP before the TLS handshake starts, the PDP MUST 287 issue a Client-Close message with an error code 15= Authentication 288 Required. 290 A PDP wishing to negotiate security with a PEP having an existing 291 non-secure connection MUST send a Client-Close with the error code 292 15= Authentication required, with the Sub-code (octet 2) containing 293 the required Integrity object's C-Num=16 and (octet 3) containing 294 the required Integrity object's C-Type=2 and wait for the PEP to 295 reconnect. Upon receiving the Client-Open message, it SHOULD use the 296 Client-Accept message to initiate security negotiation. 298 6 Connection Closure 300 TLS provides facilities to securely close its connections. Reception 301 of a valid closure alert assures an implementation that no further 302 data will arrive on that connection. The TLS specification requires 303 TLS implementations to initiate a closure alert exchange before 304 closing a connection. It also permits TLS implementations to close 305 connections without waiting to receive closure alerts from the peer, 306 provided they send their own first. A connection closed in this way 307 is known as an "incomplete close". TLS allows implementations to 308 reuse the session in this case, but COPS/TLS makes no use of this 309 capability. 311 A connection closed without first sending a closure alert is known 312 as a "premature close". Note that a premature close does not call 313 into question the security of the data already received, but simply 314 indicates that subsequent data might have been truncated. Because 315 TLS is oblivious to COPS message boundaries, it is necessary to 316 examine the COPS data itself (specifically the Message header) to 317 determine whether truncation occurred. 319 6.1 PEP System Behavior 321 PEP implementations MUST treat premature closes as errors and any 322 data received as potentially truncated. The COPS protocol allows the 323 PEP system to find out whether truncation took place. A PEP system 324 detecting an incomplete close SHOULD recover gracefully. 326 PEP systems SHOULD send a closure alert before closing the 327 connection. PEPs unprepared to receive any more data MAY choose not 328 to wait for the PDP system's closure alert and simply close the 329 connection, thus generating an incomplete close on the PDP side. 331 6.2 PDP System Behavior 333 COPS permits a PEP to close the connection at any time, and requires 334 PDPs to recover gracefully. In particular, PDPs SHOULD be prepared 335 to receive an incomplete close from the PEP, since a PEP often shuts 336 down for operational reasons unrelated to the transfer of policy 337 information between the PEP and PDP. 339 Implementation note: The PDP ordinarily expects to be able to 340 signal end of data by closing the connection. However, the PEP 341 may have already sent the closure alert and dropped the 342 connection. 344 PDP systems MUST attempt to initiate an exchange of closure alerts 345 with the PEP system before closing the connection. PDP systems MAY 346 close the connection after sending the closure alert, thus 347 generating an incomplete close on the PEP side. 349 7 Endpoint Identification and Access Control 351 All PEP implementations of COPS/TLS MUST support an access control 352 mechanism to identify authorized PDPs. This requirement provides a 353 level of assurance that the policy arriving at the PEP is actually 354 valid. PEP deployments SHOULD require the use of this access control 355 mechanism for operation of COPS over TLS. When access control is 356 enabled, the PEP implementation MUST NOT initiate COPS/TLS 357 connections to systems not authorized as PDPs by the access control 358 mechanism. 360 Similarly, PDP COPS/TLS implementations MUST support an access 361 control mechanism permitting them to restrict their services to 362 authorized PEP systems only. However, deployments MAY choose not to 363 use an access control mechanism at the PDP, as organizations might 364 not consider the types of policy being deployed as sensitive, and 365 therefore do not need to incur the expense of managing credentials 366 for the PEP systems. If access controls are used, however, the PDP 367 implementation MUST terminate COPS/TLS connections from unauthorized 368 PEP systems and log an error if an auditable logging mechanism is 369 present. 371 Implementations of COPS/TLS MUST use X.509 v3 certificates 372 conforming to [RFC3280] to identify PDP and PEP systems. COPS/TLS 373 systems MUST perform certificate verification processing conforming 374 to [RFC3280]. 376 If a subjectAltName extension of type dNSName or iPAddress is 377 present in the PDP's certificate, it MUST be used as the PDP 378 identity. If both types are present, dNSName SHOULD be used as the 379 PDP identity. If neither of the types is present, the most specific 380 Common Name field in the Subject field of the certificate SHOULD be 381 used. 383 Matching is performed using the matching rules specified by 384 [RFC3280]. If more than one identity of a given type is present in 385 the certificate (e.g. more than one dNSName name in the 386 subjectAltName certificate extension), a match in any one of the 387 provided identities is acceptable. Generally, the COPS system uses 388 the first name for matching, except as noted below in the IP 389 address checking requirements. 391 7.1 PDP Identity 393 Generally, COPS/TLS requests are generated by the PEP consulting 394 bootstrap policy information that identifies PDPs that the PEP is 395 authorized to connect to. This policy provides the PEP with the 396 hostname or IP address of the PDP. How this bootstrap policy 397 information arrives at the PEP is outside the scope of this 398 document. However, all PEP implementations MUST provide a mechanism 399 to securely deliver or configure the bootstrap policy. 401 All PEP implementations MUST be able to securely acquire the trust 402 anchor for each authorized Certification Authority (CA) that issues 403 PDP certificates. Also, the PEPs MUST support a mechanism to 404 securely acquire an access control list or filter identifying the 405 set of authorized PDPs associated with each CA. 407 PEP deployments that participate in multiple domains, such as those 408 on mobile platforms, MAY use different CAs and access control lists 409 in each domain. 411 If the PDP hostname or IP address is available via the bootstrap 412 policy, the PEP MUST check it against the PDP's identity as 413 presented in the PDP's TLS Certificate message. 415 In some cases the bootstrap policy will identify the authorized PDP 416 only by an IP address of the PDP system. In this case, the 417 subjectAltName MUST be present in the certificate, and it MUST 418 include an iPAdress format matching the expected name of the policy 419 server. 421 If the hostname of the PDP does not match the identity in the 422 certificate, a PEP on a user oriented system MUST either notify the 423 user (PEP systems MAY afford the user the opportunity to continue 424 with the connection in any case) or terminate the connection with a 425 bad certificate error. PEPs on unattended systems MUST log the error 426 to an appropriate audit log (if available) and MUST terminate the 427 connection with a bad certificate error. Unattended PEP systems MAY 428 provide a configuration setting that disables this check, but then 429 MUST provide a setting which enables it. 431 7.2 PEP Identity 433 When PEP systems are not access controlled, the PDP need have no 434 external knowledge of what the PEP's identity ought to be and so 435 checks are neither possible nor necessary. In this case, there is no 436 requirement for PEP systems to register with a certificate 437 authority, and COPS over TLS uses one-way authentication, of the PDP 438 to the PEP. 440 When PEP systems are access controlled, PEPs MUST be the subjects 441 of end entity certificates [RFC3280]. In this case, COPS over TLS 442 uses two-way authentication, and the PDP MUST perform the same 443 identity checks for the PEPs as described above for the PDP. 445 When access controls are in effect at the PDP, PDP implementations 446 MUST have a mechanism to securely acquire the trust anchor for each 447 authorized Certification Authority (CA) that issues certificates to 448 supported PEPs. 450 8 Backward Compatibility 451 The PEP and PDP SHOULD be backward compatible with peers that have 452 not been modified to support COPS/TLS. They SHOULD handle errors 453 generated in response to the Integrity-TLS object. 455 9 IANA Considerations 457 The IANA shall add the following C-Num, C-Type combination for the 458 Integrity-TLS object to the registry at 459 http://www.iana.org/assignments/cops-parameters: 460 0x10 0x02 Message Integrity, Integrity-TLS [RFCxxxx] 462 For Client-Type 0, the IANA shall add the following Flags value for 463 the Integrity-TLS object: 464 0x01 = StartTLS 466 Further, for Client-Type 0, the IANA shall add the following text 467 for Error Sub-Codes: 468 Error Code: 15 469 Error Sub-Code: 470 Octet 2: C-Num of the Integrity object 471 Octet 3: C-Type of the supported/preferred Integrity object or 472 Zero. 474 Error-Code Error-SubCode Description 475 Octet 2 Octet 3 476 --------------------------------------------------- 477 15 16 0 No security 478 15 16 2 Integrity-TLS supported/preferred 480 Further values for the Flags field and the reserved field can only 481 be assigned by IETF Consensus rule as defined in [RFC2434]. 483 10 Security Considerations 485 A COPS PDP and PEP MUST check the results of the TLS negotiation to 486 see whether an acceptable degree of authentication and privacy have 487 been achieved. If the negotiation has resulted in unacceptable 488 algorithms or key lengths, either side MAY choose to terminate the 489 connection. 491 A man-in-the-middle attack can be launched by deleting the 492 Integrity-TLS object or altering the Client-Open or Client-Accept 493 messages. If security is required, the PEP and PDP bootstrap policy 494 must specify this, and PEP and PDP implementations should reject 495 Client-Open or Client-Accept messages that fail to include an 496 Integrity-TLS object. 498 11 References 499 11.1 Normative References 501 [RFC2119] Bradner, S., "Key Words for use in RFCs to indicate 502 Requirement Levels", RFC 2119, March 1997. 504 [RFC2748] Durham, D., Boyle, J., Cohen, R., Herzog, R., Rajan, 505 R., Sastry, A., "The COPS (Common Open Policy Service) Protocol", 506 RFC 2748, January 2000. 508 [RFC2753] Yavatkar, R., Pendarakis, D., Guerin, R., "A Framework 509 for Policy-based Admission Control", RFC 2753, January 2000. 511 [RFC3280] Housley, R., Ford, W., Polk, W., Solo, D., "Internet 512 X.509 Public Key Infrastructure Certificate and Certificate 513 Revocation List (CRL) Profile ", RFC 3280, April 2002. 515 [RFC2246] Dierks, T., Allen, C., "The TLS Protocol", RFC 2246, 516 January 1999. 518 11.2 Informative References 520 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 522 [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 523 2595, June 1999. 525 [RFC2434] Alvestrand, H., Narten, T., "Guidelines for writing an 526 IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 527 1998. 529 12 Author Addresses 531 Amol Kulkarni 532 Intel Corporation 533 2111 N.E. 25th Avenue 534 Hillsboro, OR 97214 535 USA 536 amol[dot]kulkarni[at]intel[dot]com 538 Jesse R. Walker 539 Intel Corporation 540 2111 N.E. 25th Avenue 541 Hillsboro, OR 97214 542 USA 543 jesse[dot]walker[at]intel[dot]com 545 13 IPR Disclosure Acknowledgement 547 By submitting this Internet-Draft, we certify that any applicable 548 patent or other IPR claims of which we are aware have been 549 disclosed, and any of which we become aware will be disclosed, in 550 accordance with RFC 3668. 552 14 Disclaimer of Validity 554 The IETF takes no position regarding the validity or scope of any 555 Intellectual Property Rights or other rights that might be claimed 556 to pertain to the implementation or use of the technology described 557 in this document or the extent to which any license under such 558 rights might or might not be available; nor does it represent that 559 it has made any independent effort to identify any such rights. 560 Information on the procedures with respect to rights in RFC 561 documents can be found in BCP 78 and BCP 79. 563 Copies of IPR disclosures made to the IETF Secretariat and any 564 assurances of licenses to be made available, or the result of an 565 attempt made to obtain a general license or permission for the use 566 of such proprietary rights by implementers or users of this 567 specification can be obtained from the IETF on-line IPR repository 568 at http://www.ietf.org/ipr. 570 The IETF invites any interested party to bring to its attention any 571 copyrights, patents or patent applications, or other proprietary 572 rights that may cover technology that may be required to implement 573 this standard. Please address the information to the IETF at ietf- 574 ipr@ietf.org. 576 15 Copyright Statement 578 Copyright (C) The Internet Society (2004). This document is subject 579 to the rights, licenses and restrictions contained in BCP 78, and 580 except as set forth therein, the authors retain all their rights. 582 16 Disclaimer 584 This document and the information contained herein are provided on 585 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 586 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 587 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 588 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 589 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 590 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 592 17 Acknowledgements 594 This document freely plagiarizes and adapts Eric Rescorla's similar 595 document [RFC2818] that specifies how HTTP runs over TLS. 596 Discussions with David Durham, Scott Hahn and Ylian Sainte-Hillaire 597 also lead to improvements in this document. 598 The authors wish to thank Uri Blumenthal for doing a thorough 599 security review of the document. 601 Funding for the RFC Editor function is currently provided by the 602 Internet Society.