idnits 2.17.1 draft-ietf-rap-cops-tls-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 : ---------------------------------------------------------------------------- No issues found here. 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 (August 16, 2004) is 7191 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: 'RFC2753' is mentioned on line 82, but not defined == 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) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Jesse Walker 3 Expiration: February 2005 Amol Kulkarni, Ed. 4 File: draft-ietf-rap-cops-tls-08.txt Intel Corp. 6 COPS Over TLS 8 Last Updated: August 16, 2004 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of [RFC2026]. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet-Drafts 23 as reference material or to cite them other than as "work in 24 progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Conventions used in this document 34 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 35 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 36 this document are to be interpreted as described in [RFC2119]. 38 Abstract 40 This memo describes how to use TLS to secure COPS connections over 41 the Internet. 43 Please send comments on this document to the rap@ops.ietf.org 44 mailing list. 46 Table Of Contents 47 Glossary..........................................................3 48 1 Introduction...................................................3 49 2 COPS Over TLS..................................................3 50 3 Separate Ports versus Upward Negotiation.......................3 51 4 COPS/TLS Objects and Error codes...............................4 52 4.1 The StartTLS ClientSI Object..................................4 53 4.2 Error Codes...................................................4 54 5 COPS/TLS Secure Connection Initiation..........................4 55 5.1 PDP Initiated Security Negotiation............................4 56 5.2 PEP Initiated Security Negotiation............................5 57 6 Connection Closure.............................................6 58 6.1 PEP System Behavior...........................................6 59 6.2 PDP System Behavior...........................................6 60 7 Port Number....................................................7 61 8 Endpoint Identification and Access Control.....................7 62 8.1 PDP Identity..................................................8 63 8.2 PEP Identity..................................................8 64 9 Backward Compatibility.........................................9 65 10 IANA Considerations............................................9 66 11 Security Considerations........................................9 67 12 Acknowledgements...............................................9 68 13 References....................................................10 69 13.1 Normative References........................................10 70 13.2 Informative References......................................10 71 14 Author Addresses.............................................10 72 15 Intellectual Property Statement..............................11 73 16 Full Copyright Statement......................................11 75 Glossary 76 COPS - Common Open Policy Service. See [RFC2748]. 77 COPS/TCP - A plain-vanilla implementation of COPS. 78 COPS/TLS - A secure implementation of COPS using TLS. 79 PDP - Policy Decision Point. Also referred to as the Policy 80 Server. See [RFC2753]. 81 PEP - Policy Enforcement Point. Also referred to as the Policy 82 Client. See [RFC2753]. 84 1 Introduction 86 COPS [RFC2748] was designed to distribute clear-text policy 87 information from a centralized Policy Decision Point (PDP) to a set 88 of Policy Enforcement Points (PEP) in the Internet. COPS provides 89 its own security mechanisms to protect the per-hop integrity of the 90 deployed policy. However, the use of COPS for sensitive applications 91 such as some types of security policy distribution requires 92 additional security measures, such as data privacy. This is because 93 some organizations find it necessary to hide some or all of their 94 security policies, e.g., because policy distribution to devices such 95 as mobile platforms can cross domain boundaries. 97 TLS [RFC2246] was designed to provide channel-oriented security. TLS 98 standardizes SSL and may be used with any connection-oriented 99 service. TLS provides mechanisms for both one- and two-way 100 authentication, dynamic session keying, and data stream privacy and 101 integrity. 103 This document describes how to use COPS over TLS. "COPS over TLS" is 104 abbreviated COPS/TLS. 106 2 COPS Over TLS 108 COPS/TLS is very simple: use COPS over TLS similar to how you would 109 use COPS over TCP (COPS/TCP). Apart from a specific procedure used 110 to initialize the connection, there is no difference between 111 COPS/TLS and COPS/TCP. 113 3 Separate Ports versus Upward Negotiation 115 There are two ways in which insecure and secure versions of the same 116 protocol can be run simultaneously. 118 In the first method, the secure version of the protocol is also 119 allocated a well-known port. This strategy of having well-known port 120 numbers for both, the secure and insecure versions, is known as 121 'Separate Ports'. The clients requiring security can simply connect 122 to the well-known secure port. This method is easy to implement, 123 with no modifications needed to existing insecure implementations. 124 The disadvantage, however, is that it doesn't scale well, with a new 125 port required for each secure implementation. More problems with 126 this approach have been listed in [RFC2595]. 128 The second method is known as 'Upward Negotiation'. In this method, 129 the secure and insecure versions of the protocol run on the same 130 port. The client connects to the server, both discover each others' 131 capabilities, and start security negotiations if desired. This 132 method usually requires some changes to the protocol being secured. 134 COPS/TLS uses the Upward Negotiation method to secure COPS messages. 136 4 COPS/TLS Objects and Error codes 138 This section describes the COPS objects and error codes needed to 139 support COPS/TLS. 141 4.1 The StartTLS ClientSI Object 143 The StartTLS ClientSI object is used by the PDP and the PEP to start 144 the TLS negotiation. This object can be included either in the 145 ClientAccept message, or a Request message. Also, the ClientType of 146 any message containing this ClientSI object MUST be 0. 148 0 1 2 3 149 +----------+----------+----------+----------+ 150 | Length (Octets) | C-Num=9 | C-Type=1 | 151 +----------+----------+----------+----------+ 152 | //////// | Flags | 153 +----------+----------+----------+----------+ 155 Flags: 156 1 = TLS 158 4.2 Error Codes 160 This section adds to the error codes described in section 2.2.8 161 (Error Object) of [RFC2748]. 163 Error Code: 16 = TLS Required 165 This error code should be used by either PEP or PDP if they require 166 security but the other side doesn't support it. 168 5 COPS/TLS Secure Connection Initiation 170 Security negotiation may be initiated either by the PDP or the PEP. 171 The PDP can initiate a security negotiation either via a 172 ClientAccept or a ClientClose message, while a PEP can initiate a 173 negotiation via a Request message. 175 Once the TLS connection is established, all COPS data MUST be sent 176 as TLS "application data". 178 5.1 PDP Initiated Security Negotiation 179 The PEP initially opens a TCP connection with the PDP on the 180 standard COPS port and sends a ClientOpen message. This ClientOpen 181 message MUST have a ClientType of 0. 183 The PDP then replies with a ClientAccept. In order to signal the PEP 184 to start the TLS handshake, the PDP MUST include the StartTLS 185 ClientSI object in the ClientAccept message. 187 Note that in order to carry the StartTLS ClientSI object, the 188 contents of the ClientAccept message defined in section 3.7 of 189 [RFC2748] need to change to the following: 191 ::= 192 193 [] 194 [] 195 [] 197 Upon receiving the ClientAccept message with the StartTLS ClientSI 198 object, the PEP SHOULD initiate the TLS handshake. If for any reason 199 the PEP cannot initiate the handshake, it MUST close the connection. 201 The message exchange is as follows: 202 C: ClientOpen (ClientType = 0) 203 S: ClientAccept (ClientType = 0, StartTLS) 204 205 C/S: <...further messages...> 207 Until the TLS handshake is complete the PEP MUST NOT send any 208 messages other than ClientClose and KeepAlive. Upon receiving any 209 other message, a PDP expecting a TLS negotiation MUST issue a 210 ClientClose message with an error code of 16. 212 5.2 PEP Initiated Security Negotiation 214 If a PEP wishes to use TLS on an existing non-secure COPS 215 connection, it MUST issue a Request message with a ClientType of 0. 216 The StartTLS ClientSI object MUST be included in the request. 218 In response, the PDP SHOULD send a Decision message containing the 219 appropriate Command-Code (1 = Install/Accept, 2 = Remove/Reject) in 220 the Decision Flags object. 222 If the request is accepted, the PEP MUST start the TLS handshake. 223 After the TLS handshake is complete, the PDP MUST synchronize state 224 with the PEP. 226 The message exchange is as follows: 227 <...existing COPS/TCP connection...> 228 C: Request (ClientType = 0, StartTLS) 229 S: Decision (ClientType = 0, Install) 230 231 S: Synchronize 232 If the PEP's TLS request is rejected by the PDP, the PEP MAY choose 233 to continue using the non-secure connection. Else, it MUST close the 234 connection by sending a ClientClose message with an error code of 235 16. 237 6 Connection Closure 239 TLS provides facilities to securely close its connections. Reception 240 of a valid closure alert assures an implementation that no further 241 data will arrive on that connection. The TLS specification requires 242 TLS implementations to initiate a closure alert exchange before 243 closing a connection. It also permits TLS implementations to close 244 connections without waiting to receive closure alerts from the peer, 245 provided they send their own first. A connection closed in this way 246 is known as an "incomplete close". TLS allows implementations to 247 reuse the session in this case, but COPS/TLS makes no use of this 248 capability. 250 A connection closed without first sending a closure alert is known 251 as a "premature close". Note that a premature close does not call 252 into question the security of the data already received, but simply 253 indicates that subsequent data might have been truncated. Because 254 TLS is oblivious to COPS message boundaries, it is necessary to 255 examine the COPS data itself (specifically the Message header) to 256 determine whether truncation occurred. 258 6.1 PEP System Behavior 260 PEP implementations MUST treat premature closes as errors and any 261 data received as potentially truncated. The COPS protocol allows the 262 PEP system to find out whether truncation took place. A PEP system 263 detecting an incomplete close SHOULD recover gracefully. 265 PEP systems MUST send a closure alert before closing the connection. 266 PEPs unprepared to receive any more data MAY choose not to wait for 267 the PDP system's closure alert and simply close the connection, thus 268 generating an incomplete close on the PDP side. 270 6.2 PDP System Behavior 272 COPS permits a PEP to close the connection at any time, and requires 273 PDPs to recover gracefully. In particular, PDPs SHOULD be prepared 274 to receive an incomplete close from the PEP, since a PEP often shuts 275 down for operational reasons unrelated to the transfer of policy 276 information between the PEP and PDP. 278 Implementation note: The PDP ordinarily expects to be able to 279 signal end of data by closing the connection. However, the PEP 280 may have already sent the closure alert and dropped the 281 connection. 283 PDP systems MUST attempt to initiate an exchange of closure alerts 284 with the PEP system before closing the connection. PDP systems MAY 285 close the connection after sending the closure alert, thus 286 generating an incomplete close on the PEP side. 288 7 Port Number 290 The first data a PDP expects to receive from the PEP is a Client- 291 Open message. The first data a TLS server (and hence a COPS/TLS PDP) 292 expects to receive is the ClientHello. Consequently, COPS/TLS runs 293 over a separate port in order to distinguish it from COPS alone. 294 When COPS/TLS runs over a TCP/IP connection, the TCP port is any 295 non-well-known port of the PDP's choice. This port MUST be 296 communicated to the COPS/TCP PDP running on the well-known COPS TCP 297 port. The PEP may use any TCP port. This does not preclude COPS/TLS 298 from running over another transport. TLS only presumes a reliable 299 connection-oriented data stream. 301 8 Endpoint Identification and Access Control 303 All PEP implementations of COPS/TLS MUST support an access control 304 mechanism to identify authorized PDPs. This requirement provides a 305 level of assurance that the policy arriving at the PEP is actually 306 valid. PEP implementations SHOULD require the use of this access 307 control mechanism for operation of COPS over TLS. When access 308 control is enabled, the PEP implementation MUST NOT initiate 309 COPS/TLS connections to systems not authorized as PDPs by the access 310 control mechanism. 312 Similarly, PDP COPS/TLS implementations MUST support an access 313 control mechanism permitting them to restrict their services to 314 authorized PEP systems only. However, implementations MAY choose not 315 to use an access control mechanism at the PDP, as organizations 316 might not consider the types of policy being deployed as sensitive, 317 and therefore do not need to incur the expense of managing 318 credentials for the PEP systems. If access controls are used, 319 however, the PDP implementation MUST terminate COPS/TLS connections 320 from unauthorized PEP systems and log an error if an auditable 321 logging mechanism is present. 323 Implementations of COPS/TLS MUST use X.509 v3 certificates 324 conforming to [RFC3280] to identify PDP and PEP systems. COPS/TLS 325 systems MUST perform certificate verification processing conforming 326 to [RFC3280]. 328 If a subjectAltName extension of type dNSName or iPAddress is 329 present in the PDP's certificate, it MUST be used as the PDP 330 identity. If both types are present, dNSName SHOULD be used as the 331 PDP identity. If neither of the types is present, the most specific 332 Common Name field in the Subject field of the certificate SHOULD be 333 used. 335 Matching is performed using the matching rules specified by 336 [RFC3280]. If more than one identity of a given type is present in 337 the certificate (e.g. more than one dNSName name in the 338 subjectAltName certificate extension), a match in any one of the 339 provided identities is acceptable. Generally, the COPS system uses 340 the first name for matching, except as noted below in the IP 341 address checking requirements. 343 8.1 PDP Identity 345 Generally, COPS/TLS requests are generated by the PEP consulting 346 bootstrap policy information that identifies PDPs that the PEP is 347 authorized to connect to. This policy provides the PEP with the 348 hostname or IP address of the PDP. How this bootstrap policy 349 information arrives at the PEP is outside the scope of this 350 document. However, all PEP implementations MUST provide a mechanism 351 to securely deliver or configure the bootstrap policy. 353 All PEP implementations MUST be able to securely acquire the signing 354 certificates of authorized Certificate Authorities that issue PDP 355 certificates. Also, the PEPs MUST support a mechanism to securely 356 acquire an access control list or filter identifying the CA's set of 357 authorized PDPs. 359 PEP implementations that participate in multiple domains, such as 360 those on mobile platforms, MAY use different CAs and access control 361 lists in each domain. 363 If the PDP hostname or IP address is available via the bootstrap 364 policy, the PEP MUST check it against the PDP's identity as 365 presented in the PDP's TLS Certificate message. 367 In some cases the bootstrap policy will identify the authorized PDP 368 only by an IP address of the PDP system. In this case, the 369 subjectAltName MUST be present in the certificate, and it MUST 370 include an iPAdress format matching the expected name of the policy 371 server. 373 If the hostname of the PDP does not match the identity in the 374 certificate, a PEP on a user oriented system MUST either notify the 375 user (PEP systems MAY afford the user the opportunity to continue 376 with the connection in any case) or terminate the connection with a 377 bad certificate error. PEPs on unattended systems MUST log the error 378 to an appropriate audit log (if available) and MUST terminate the 379 connection with a bad certificate error. Unattended PEP systems MAY 380 provide a configuration setting that disables this check, but then 381 MUST provide a setting which enables it. 383 8.2 PEP Identity 385 When PEP systems are not access controlled, the PDP need have no 386 external knowledge of what the PEP's identity ought to be and so 387 checks are neither possible nor necessary. In this case, there is no 388 requirement for PEP systems to register with a certificate 389 authority, and COPS over TLS uses one-way authentication, of the PDP 390 to the PEP. 392 When PEP systems are access controlled, PEPs MUST be PKI clients in 393 the sense of [RFC3280]. In this case, COPS over TLS uses two-way 394 authentication, and the PDP MUST perform the same identity checks 395 for the PEPs as described above for the PDP. 397 When access controls are in effect at the PDP, PDP implementations 398 MUST have a mechanism to securely acquire the signing certificates 399 of the Certificate Authorities issuing certificates to any of the 400 PEPs they support. 402 9 Backward Compatibility 404 The PEP and PDP SHOULD be backward compatible with peers that have 405 not been modified to support COPS/TLS. They SHOULD handle errors 406 generated in response to the StartTLS ClientSI object. 408 In case a PEP does not start the TLS handshake upon receiving the 409 StartTLS ClientSI object, the PDP MUST close the connection. 411 10 IANA Considerations 413 The IANA shall add the following Error-Code to the cops-parameters 414 document: 416 Error-Code: 16 417 Description: TLS Required 419 11 Security Considerations 421 A COPS PDP and PEP MUST check the results of the TLS negotiation to 422 see whether an acceptable degree of authentication and privacy have 423 been achieved. If the negotiation has resulted in unacceptable 424 algorithms or key lengths, either side MAY choose to terminate the 425 connection. 427 A man-in-the-middle attack can be launched by deleting the StartTLS 428 ClientSI object from the ClientAccept or Request messages. To 429 prevent this, the PEP and PDP MUST use the Integrity object as 430 defined in [RFC2748]. 432 A downgrade attack against a PEP requesting TLS negotiation is 433 possible by modifying the PDP's Decision message flag to 'Remove'. 434 Again, this can be avoided by using the Integrity object as defined 435 in [RFC2748]. 437 12 Acknowledgements 439 This document freely plagiarizes and adapts Eric Rescorla's similar 440 document [RFC2818] that specifies how HTTP runs over TLS. 442 Discussions with David Durham, Scott Hahn and Ylian Sainte-Hillaire 443 also lead to improvements in this document. 444 The authors wish to thank Uri Blumenthal for doing a thorough 445 security review of the document. 447 13 References 448 13.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 13.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 14 Author Addresses 479 Jesse R. Walker 480 Intel Corporation 481 2111 N.E. 25th Avenue 482 Hillsboro, OR 97214 483 USA 484 jesse.walker[at]intel.com 486 Amol Kulkarni 487 Intel Corporation 488 JF3-206 489 2111 N.E. 25th Avenue 490 Hillsboro, OR 97214 491 USA 492 amol.kulkarni[at]intel.com 494 15 Intellectual Property Statement 496 The IETF takes no position regarding the validity or scope of any 497 intellectual property or other rights that might be claimed to 498 pertain to the implementation or use of the technology described in 499 this document or the extent to which any license under such rights 500 might or might not be available; neither does it represent that it 501 has made any effort to identify any such rights. Information on the 502 IETF's procedures with respect to rights in standards-track and 503 standards-related documentation can be found in BCP-11. Copies of 504 claims of rights made available for publication and any assurances 505 of licenses to be made available, or the result of an attempt made 506 to obtain a general license or permission for the use of such 507 proprietary rights by implementors or users of this specification 508 can be obtained from the IETF Secretariat. 510 The IETF invites any interested party to bring to its attention any 511 copyrights, patents or patent applications, or other proprietary 512 rights which may cover technology that may be required to practice 513 this standard. Please address the information to the IETF Executive 514 Director. 516 The IETF has been notified of intellectual property rights claimed 517 in regard to some or all of the specification contained in this 518 document. For more information consult the online list of claimed 519 rights. 521 16 Full Copyright Statement 523 Copyright (C) The Internet Society (2004). All Rights Reserved. 525 This document and translations of it may be copied and furnished to 526 others, and derivative works that comment on or otherwise explain it 527 or assist in its implementation may be prepared, copied, published 528 and distributed, in whole or in part, without restriction of any 529 kind, provided that the above copyright notice and this paragraph 530 are included on all such copies and derivative works. However, this 531 document itself may not be modified in any way, such as by removing 532 the copyright notice or references to the Internet Society or other 533 Internet organizations, except as needed for the purpose of 534 developing Internet standards in which case the procedures for 535 copyrights defined in the Internet Standards process must be 536 followed, or as required to translate it into languages other than 537 English. 539 The limited permissions granted above are perpetual and will not be 540 revoked by the Internet Society or its successors or assignees. 542 This document and the information contained herein is provided on an 543 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 544 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 545 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 546 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 547 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.