idnits 2.17.1 draft-ietf-rap-cops-tls-05.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 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 6, 2003) is 7747 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: 'RFC-2119' is mentioned on line 37, but not defined == Unused Reference: 'RFC2026' is defined on line 479, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 482, but no explicit reference was found in the text == Unused Reference: 'RFC2818' is defined on line 498, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2459 (ref. 'PKIX') (Obsoleted by RFC 3280) ** Obsolete normative reference: RFC 2246 (ref. 'TLS') (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: July 2003 Amol Kulkarni 4 File: draft-ietf-rap-cops-tls-05.txt Intel Corp. 6 COPS Over TLS 8 Last Updated: February 6, 2003 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 [RFC-2119]. 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 1 Introduction...................................................3 48 2 COPS Over TLS..................................................3 49 3 Separate Ports versus Upward Negotiation........................3 50 3.1 The COPS/TLS approach.........................................4 51 3.2.1 The ClientSI object format..................................4 52 3.2.2 Error Codes and Sub-Codes...................................5 53 4 Usage Scenarios.................................................5 54 4.1 Security Required By Client and Server........................5 55 4.2 Security Required By Client and Optional on Server............5 56 4.3 Security Optional on Client and Required on Server............6 57 4.4 Security Optional on Client and Server........................6 58 4.5 Security Supported by Client but not by Server................6 59 4.6 Security supported by Server but not by Client................6 60 4.7 Security not Supported by either Client or Server.............6 61 5 Secure Connection Initiation....................................6 62 6 Connection Closure..............................................7 63 6.1. PEP System Behavior.........................................7 64 6.2. PDP System Behavior.........................................7 65 7 Port Number.....................................................8 66 8 Endpoint Identification and Access Control.....................8 67 8.1 PDP Identity.................................................8 68 8.2 PEP Identity.................................................9 69 9 Other Considerations...........................................10 70 9.1 Backward Compatibility.......................................10 71 9.2 IANA Considerations..........................................10 72 10 Security Considerations......................................10 73 11 Acknowledgements.............................................10 74 12 References....................................................10 75 12.1 Normative References........................................10 76 12.2 Informative References......................................10 77 13 Authors' Addresses...........................................11 79 1 Introduction 81 COPS [COPS] was designed to distribute clear-text policy information 82 from a centralized Policy Decision Point (PDP) to a set of Policy 83 Enforcement Points (PEP) in the Internet. COPS provides its own 84 security mechanisms to protect the per-hop integrity of the deployed 85 policy. However, the use of COPS for sensitive applications such as 86 some types of security policy distribution requires additional 87 security measures, such as data privacy. This is because some 88 organizations find it necessary to hide some or all of their 89 security policies, e.g., because policy distribution to devices such 90 as mobile platforms can cross domain boundaries. 92 TLS [TLS] was designed to provide channel-oriented security. TLS 93 standardizes SSL and may be used with any connection-oriented 94 service. TLS provides mechanisms for both one- and two-way 95 authentication, dynamic session keying, and data stream privacy and 96 integrity. 98 This document describes how to use COPS over TLS. "COPS over TLS" is 99 abbreviated COPS/TLS. 101 2 COPS Over TLS 103 COPS/TLS is very simple: use COPS over TLS similar to how you would 104 use COPS over TCP (COPS/TCP). Apart from a specific procedure used 105 to initialize the connection, there is no difference between 106 COPS/TLS and COPS/TCP. 108 3 Separate Ports versus Upward Negotiation 110 There are two ways in which insecure and secure versions of the same 111 protocol can be run simultaneously. 113 In the first method, the secure version of the protocol is also 114 allocated a well-known port. This strategy of having well-known port 115 numbers for both, the secure and insecure versions, is known as 116 'Separate Ports'. The clients requiring security can simply connect 117 to the well-known secure port. The main advantage of this strategy 118 is that it is very simple to implement, with no modifications needed 119 to existing insecure implementations. Thus it is the most popular 120 approach. The disadvantage, however, is that it doesn't scale well, 121 with a new port required for each secure implementation. Hence, the 122 IESG discourages designers from using the strategy. 124 The second method is known as 'Upward Negotiation'. In this method, 125 the secure and insecure versions of the protocol run on the same 126 port. The client connects to the server, both discover each others' 127 capabilities, and start security negotiations if desired. This 128 method usually requires some changes in the protocol being secured 129 so that it can support the upward negotiation. There is also a high 130 handshake overhead involved in this method. 132 3.1 The COPS/TLS approach 134 COPS/TLS uses a combination of both these approaches to achieve 135 simultaneous operation with COPS/TCP. Initially, the authors had 136 hoped to use the Separate Ports strategy for implementing COPS/TLS, 137 however, due to the reluctance of the IESG to assign a well-known 138 port, they settled on the following approach. 140 When the COPS/TLS server is initialized, it SHOULD bind to any non- 141 well-known port of its choice. The standard COPS server running over 142 TCP MUST know the TCP port on which COPS/TLS is running. How this is 143 achieved is outside the scope of this document. 145 The system acting as the PEP also acts as the TLS client. It needs 146 to first connect to the COPS/TCP server, from where it can be 147 redirected to the COPS/TLS server. 149 3.2 Object Format and Error Codes 151 This section describes the ClientSI object sent in the ClientOpen 152 message and the error codes the server returns. 154 3.2.1 The ClientSI object format 156 0 1 2 3 157 +----------+----------+----------+----------+ 158 | Length (Octets) | C-Num=9 | C-Type=2 | 159 +----------+----------+----------+----------+ 160 | Protocol | Flags | 161 +----------+----------+----------+----------+ 162 | : : : | 163 // : : : // 164 +----------+----------+----------+----------+ 165 | Protocol | Flags | 166 +----------+----------+----------+----------+ 168 Protocol: 169 1 = TLS 171 Flags: 172 0 = Protocol Support Optional 173 1 = Protocol Support Required 175 This ClientSI object MUST be included with the ClientOpen message 176 (Client Type = 0) when the client supports security. For each 177 supported protocol, there MUST be a 32 bit Protocol+Flags pair 178 appended to the object. At present, only one protocol (TLS) is 179 described. However, the ClientSI object definition is general enough 180 to allow addition of new protocols in the future. 182 If multiple protocols are supported by the client, it MUST ensure 183 that no more than one has the 'Protocol Support Required' flag set. 184 Note that it is also valid to mark all protocols as optional. 186 3.2.2 Error Codes and Sub-Codes 188 This section adds to, and modifies, the error codes described in 189 section 2.2.8 (Error Object) of [COPS]. 191 Error Code: 12 = Redirect to Preferred Server: 192 Sub-code: 193 0 = Regular redirect (no security necessary) 194 1 = Use TLS 195 Error Code: 16 = Security Failure 196 17 = Security Required 198 A new error sub-code has been added to the pre-existing error code 199 12. The sub-code informs the client that it SHOULD use TLS when 200 connecting to the redirected server. In the future, more sub-codes 201 may be added to specify additional protocols. 203 Error Code 17 MAY be used by either Client or Server if they require 204 security but the other side doesn't support it. 206 4 Usage Scenarios 208 When the client needs to open a secure connection with the server, 209 it SHOULD first connect to the non-secure port, and send a Client 210 Open message with a ClientType=0. Included in this message, MUST be 211 a ClientSI object, which lists the security capabilities of the 212 client. 213 The following scenarios occur: 215 4.1 Security Required By Client and Server 217 If the server's internal policies allow the client to connect, the 218 server MUST send a ClientClose message with a Redirect object, 219 redirecting the client to the COPS/TLS secure port. Additionally, 220 the error object included in the ClientClose message MUST have the 221 error code = 12 and sub code = 1. 223 If the server's internal policies do not allow the client to 224 connect, the server MUST send a ClientClose with an appropriate 225 error code. 227 4.2 Security Required By Client and Optional on Server 229 If the server's internal policies allow the client to connect 230 securely, the server MUST send a ClientClose message with a Redirect 231 object, redirecting the client to the COPS/TLS secure port. 232 Additionally, the error object included in the ClientClose message 233 MUST have the error code = 12 and sub code = 1. 235 If the server's internal policies do not allow the client to connect 236 securely, the server MUST send a ClientClose with error code 16 or 237 another more appropriate error code. 239 4.3 Security Optional on Client and Required on Server 241 Depending upon its internal policies, the server MAY send a 242 ClientClose message with a Redirect object, redirecting the client 243 to the COPS/TLS secure port. 245 4.4 Security Optional on Client and Server 247 Depending upon its internal policies, the server MAY send a 248 ClientClose message with a Redirect object, redirecting the client 249 to the COPS/TLS secure port. 251 Optionally, the server MAY proceed to establish an insecure 252 connection over COPS/TCP. 254 4.5 Security Supported by Client but not by Server 256 If the Client's capabilities specify that security is optional, the 257 server MAY proceed to establish an insecure connection. Otherwise, 258 it MUST send a ClientClose with the error code 16. 260 4.6 Security supported by Server but not by Client 262 If security is required by the server it MUST send a ClientClose 263 with the error code 16. If security is optional on the server, it 264 MAY establish an insecure connection with the client. 266 4.7 Security not Supported by either Client or Server 268 This is the regular COPS/TCP case as described in [COPS]. In this 269 case, only an insecure connection is possible. 271 5 Secure Connection Initiation 273 Once the PEP receives a redirect from the COPS/TCP server, it 274 initiates a connection to the PDP to the secure COPS port. When this 275 succeeds, the PEP system sends the TLS ClientHello to begin the TLS 276 handshake. When the TLS handshake completes, the PEP MAY initiate 277 the first COPS message. All COPS data MUST be sent as TLS 278 "application data". Normal COPS behavior follows. 280 All PEP implementations of COPS/TLS MUST support an access control 281 mechanism to identify authorized PDPs. This requirement provides a 282 level of assurance that the policy arriving at the PEP is actually 283 valid. The access control mechanism implemented is outside the scope 284 of this document. PEP implementations SHOULD require the use of this 285 access control mechanism for operation of COPS over TLS. When access 286 control is enabled, the PEP implementation MUST NOT initiate 287 COPS/TLS connections to systems not authorized as PDPs by the access 288 control mechanism. 290 Similarly, PDP COPS/TLS implementations MUST support an access 291 control mechanism permitting them to restrict their services to 292 authorized PEP systems only. However, implementations MUST NOT 293 require the use of an access control mechanism at the PDP, as 294 organizations might not consider the types of policy being deployed 295 as sensitive, and therefore do not need to incur the expense of 296 managing credentials for the PEP systems. If access controls are 297 used, however, the PDP implementation MUST terminate COPS/TLS 298 connections from unauthorized PEP systems and log an error if an 299 auditable logging mechanism is present. 301 6 Connection Closure 303 TLS provides facilities to securely close its connections. Reception 304 of a valid closure alert assures an implementation that no further 305 data will arrive on that connection. The TLS specification requires 306 TLS implementations to initiate a closure alert exchange before 307 closing a connection. It also permits TLS implementations to close 308 connections without waiting to receive closure alerts from the peer, 309 provided they send their own first. A connection closed in this way 310 is known as an "incomplete close". TLS allows implementations to 311 reuse the session in this case, but COPS/TLS makes no use of this 312 capability. 314 A connection closed without first sending a closure alert is known 315 as a "premature close". Note that a premature close does not call 316 into question the security of the data already received, but simply 317 indicates that subsequent data might have been truncated. Because 318 TLS is oblivious to COPS message boundaries, it is necessary to 319 examine the COPS data itself (specifically the Message header) to 320 determine whether truncation occurred. 322 6.1. PEP System Behavior 324 PEP implementations MUST treat premature closes as errors and any 325 data received as potentially truncated. The COPS protocol allows the 326 PEP system to find out whether truncation took place. A PEP system 327 detecting an incomplete close SHOULD recover gracefully. 329 PEP systems MUST send a closure alert before closing the connection. 330 Clients unprepared to receive any more data MAY choose not to wait 331 for the PDP system's closure alert and simply close the connection, 332 thus generating an incomplete close on the PDP side. 334 6.2. PDP System Behavior 336 COPS permits a PEP to close the connection at any time, and requires 337 PDPs to recover gracefully. In particular, PDPs SHOULD be prepared 338 to receive an incomplete close from the PEP, since a PEP often shuts 339 down for operational reasons unrelated to the transfer of policy 340 information between the PEP and PDP. 342 Implementation note: The PDP ordinarily expects to be able to 343 signal end of data by closing the connection. However, the PEP 344 may have already sent the closure alert and dropped the 345 connection. 347 PDP systems MUST attempt to initiate an exchange of closure alerts 348 with the PEP system before closing the connection. PDP systems MAY 349 close the connection after sending the closure alert, thus 350 generating an incomplete close on the PEP side. 352 7 Port Number 354 The first data a PDP expects to receive from the PEP is a Client- 355 Open message. The first data a TLS server (and hence a COPS/TLS 356 server) expects to receive is the ClientHello. Consequently, 357 COPS/TLS runs over a separate port in order to distinguish it from 358 COPS alone. When COPS/TLS runs over a TCP/IP connection, the TCP 359 port is any non-well-known port of the PDP's choice. This port MUST 360 be communicated to the COPS/TCP server running on the well-known 361 COPS TCP port. The PEP may use any TCP port. This does not preclude 362 COPS/TLS from running over another transport. TLS only presumes a 363 reliable connection-oriented data stream. 365 8 Endpoint Identification and Access Control 367 Implementations of COPS/TLS MUST use X.509 v3 certificates 368 conforming to [PKIX] to identify PDP and PEP systems. COPS/TLS 369 systems MUST perform certificate verification processing conforming 370 to [PKIX]. 372 If a subjectAltName extension of type dNSName or iPAddress is 373 present in the PDP's certificate, that MUST be used as the PDP 374 identity. Otherwise, the most specific Common Name field in the 375 Subject field of the certificate MUST be used. 377 Matching is performed using the matching rules specified by [PKIX]. 378 If more than one identity of a given type is present in the 379 certificate (e.g. more than one dNSName name, a match in any one of 380 the set is considered acceptable.), the COPS system uses the first 381 name to match, except as noted below in the IP address checking 382 requirements. Names may contain the wildcard character * which is 383 considered to match any single domain name component or component 384 fragment. For example, *.a.com matches foo.a.com but not 385 bar.foo.a.com. f*.com matches foo.com but not foo.bar.com. 387 8.1 PDP Identity 389 Generally, COPS/TLS requests are generated by the PEP consulting 390 bootstrap policy information identifying authorized PDPs. As a 391 consequence, the hostname or IP address for the PDP is known to the 392 PEP. How this bootstrap policy information arrives at the PEP is 393 outside the scope of this document. However, all PEP implementations 394 MUST provide a mechanism to securely deliver or configure the 395 bootstrap policy. In particular, all PEP implementations MUST 396 support a mechanism to securely acquire the signing certificate of 397 the authorized certificate authorities issuing PDP certificates, and 398 MUST support a mechanism to securely acquire an access control list 399 or filter identifying its set of authorized PDPs. 401 PEP implementations that participate in multiple domains, such as 402 those on mobile platforms, MAY use different certificate authorities 403 and access control lists in each domain. 405 Organizations may choose to deliver some or all of the bootstrap 406 policy configuration from an untrusted source, such as DHCP. In this 407 circumstance, COPS over TLS provides no protection from attack when 408 this untrusted source is compromised. 410 If the PDP hostname or IP address is available via the access 411 control mechanism, the PEP MUST check it against the PDP's identity 412 as presented in the PDP's TLS Certificate message. 414 In some cases the bootstrap policy will identify the authorized PDP 415 only by an IP address of the PDP system. In this case, the 416 subjectAltName MUST be present in the certificate, and it MUST 417 include an iPAdress format matching the expected name of the policy 418 server. 420 If the hostname of the PDP does not match the identity in the 421 certificate, a PEP on a user oriented system MUST either notify the 422 user (PEP systems MAY afford the user the opportunity to continue 423 with the connection in any case) or terminate the connection with a 424 bad certificate error. PEPs on unattended systems MUST log the error 425 to an appropriate audit log (if available) and MUST terminate the 426 connection (with a bad certificate error). Unattended PEP systems 427 MAY provide a configuration setting that disables this check, but 428 then MUST provide a setting which enables it. 430 8.2 PEP Identity 432 When PEP systems are not access controlled, the PDP need have no 433 external knowledge of what the PEP's identity ought to be and so 434 checks are neither possible nor necessary. In this case, there is no 435 requirement for PEP systems to register with a certificate 436 authority, and COPS over TLS uses one-way authentication, of the PDP 437 to the PEP. 439 When PEP systems are access controlled, PEPs must be PKI clients in 440 the sense of [PKIX]. In this case, COPS over TLS uses two-way 441 authentication, and the PDP MUST perform the same identity checks 442 for the PEPs as described above for the PDP. 444 When access controls are in effect at the PDP, PDP implementations 445 MUST have a mechanism to securely acquire the signing certificates 446 of the certificate authorities issuing certificates to any of the 447 PEPs they support. 449 9 Other Considerations 451 9.1 Backward Compatibility 452 The client and server SHOULD be backward compatible with peers that 453 do not support security. A client SHOULD be able to handle errors 454 generated by a server which does not understand the ClientSI object 455 mentioned above. Similarly, if a server receives a ClientOpen for 456 Client type=0, which does not contain the ClientSI object, it SHOULD 457 assume that the client wishes to open a non-secure connection and 458 proceed accordingly. 460 9.2 IANA Considerations 462 This draft defines some new error codes and sub codes which require 463 IANA approval. Section 3.2.2 has more details on these codes. 465 10 Security Considerations 467 This entire document concerns security. 469 11 Acknowledgements 471 This document freely plagiarizes and adapts Eric Rescorla's similar 472 document RFC2818 that specifies how HTTP runs over TLS. Discussions 473 with David Durham, Scott Hahn and Ylian Sainte-Hillaire also lead to 474 improvements in this document. 476 12 References 477 12.1 Normative References 479 [RFC2026] Bradner, S., "The Internet Standards Process - Revision 480 3", RFC 2026, October 1996 482 [RFC2119] Bradner, S., "Key Words for use in RFCs to indicate 483 Requirement Levels", RFC 2119, March 1997. 485 [COPS] Durham, D., Boyle, J., Cohen, R., Herzog, R., Rajan, R., 486 Sastry, A., "The COPS (Common Open Policy Service) Protocol", RFC 487 2748, January 200. 489 [PKIX] Housley, R., Ford, W., Polk, W., Solo, D., "Internet 490 Public Key Infrastructure: Part I: X.509 Certificate and CRL 491 Profile", RFC 2459, January 1999. 493 [TLS] Dierks, T., Allen, C., "The TLS Protocol", RFC2246, January 494 1999. 496 12.2 Informative References 498 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC2818, May 2000. 500 13 Authors' Addresses 502 Jesse R. Walker 503 Intel Corporation 504 2111 N.E. 25th Avenue 505 Hillsboro, OR 97214 506 USA 507 jesse.walker@intel.com 509 Amol Kulkarni 510 Intel Corporation 511 JF3-206 512 2111 N.E. 25th Avenue 513 Hillsboro, OR 97214 514 USA 515 amol.kulkarni@intel.com