idnits 2.17.1 draft-ietf-rap-cops-tls-04.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 : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == 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 (June 30, 2002) is 7964 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 35, but not defined == Unused Reference: 'RFC2026' is defined on line 478, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 481, but no explicit reference was found in the text == Unused Reference: 'RFC2818' is defined on line 487, 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 normative reference: RFC 2818 (Obsoleted by RFC 9110) Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Jesse Walker 2 Expiration: December 2002 Amol Kulkarni 3 File: draft-ietf-rap-cops-tls-04.txt Intel Corp. 5 COPS Over TLS 7 Last Updated: June 30, 2002 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as 22 reference material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Conventions used in this document 32 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 33 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 34 this document are to be interpreted as described in [RFC-2119]. 36 Abstract 38 This memo describes how to use TLS to secure COPS connections over 39 the Internet. 41 Please send comments on this document to the rap@ops.ietf.org 42 mailing list. 44 Table Of Contents 45 1 Introduction....................................................3 46 2 COPS Over TLS...................................................3 47 3 Separate Ports versus Upward Negotiation.........................3 48 3.1 The COPS/TLS approach..........................................4 49 3.2.1 The ClientSI object format...................................4 50 3.2.2 Error Codes and Sub-Codes....................................5 51 4 Usage Scenarios..................................................5 52 4.1 Security Required By Client and Server.........................5 53 4.2 Security Required By Client and Optional on Server.............5 54 4.3 Security Optional on Client and Required on Server.............6 55 4.4 Security Optional on Client and Server.........................6 56 4.5 Security Supported by Client but not by Server.................6 57 4.6 Security supported by Server but not by Client.................6 58 4.7 Security not Supported by either Client or Server..............6 59 5 Secure Connection Initiation.....................................6 60 6 Connection Closure...............................................7 61 6.1. PEP System Behavior..........................................7 62 6.2. PDP System Behavior..........................................7 63 7 Port Number......................................................8 64 8 Endpoint Identification and Access Control......................8 65 8.1 PDP Identity..................................................8 66 8.2 PEP Identity..................................................9 67 9 Other Considerations............................................10 68 9.1 Backward Compatibility........................................10 69 9.2 IANA Considerations...........................................10 70 10 Security Considerations.......................................10 71 11 Acknowledgements..............................................10 72 12 References....................................................10 73 12 Author Addresses..............................................10 75 1 Introduction 77 COPS [COPS] was designed to distribute clear-text policy information 78 from a centralized Policy Decision Point (PDP) to a set of Policy 79 Enforcement Points (PEP) in the Internet. COPS provides its own 80 security mechanisms to protect the per-hop integrity of the deployed 81 policy. However, the use of COPS for sensitive applications such as 82 some types of security policy distribution requires additional 83 security measures, such as data privacy. This is because some 84 organizations find it necessary to hide some or all of their security 85 policies, e.g., because policy distribution to devices such as mobile 86 platforms can cross domain boundaries. 88 TLS [TLS] was designed to provide channel-oriented security. TLS 89 standardizes SSL and may be used with any connection-oriented 90 service. TLS provides mechanisms for both one- and two-way 91 authentication, dynamic session keying, and data stream privacy and 92 integrity. 94 This document describes how to use COPS over TLS. "COPS over TLS" is 95 abbreviated COPS/TLS. 97 2 COPS Over TLS 99 COPS/TLS is very simple: use COPS over TLS similar to how you would 100 use COPS over TCP (COPS/TCP). Apart from a specific procedure used to 101 initialize the connection, there is no difference between COPS/TLS 102 and COPS/TCP. 104 3 Separate Ports versus Upward Negotiation 106 There are two ways in which insecure and secure versions of the same 107 protocol can be run simultaneously. 109 In the first method, the secure version of the protocol is also 110 allocated a well-known port. This strategy of having well-known port 111 numbers for both, the secure and insecure versions, is known as 112 'Separate Ports'. The clients requiring security can simply connect 113 to the well-known secure port. The main advantage of this strategy is 114 that it is very simple to implement, with no modifications needed to 115 existing insecure implementations. Thus it is the most popular 116 approach. The disadvantage, however, is that it doesn't scale well, 117 with a new port required for each secure implementation. Hence, the 118 IESG discourages designers from using the strategy. 120 The second method is known as 'Upward Negotiation'. In this method, 121 the secure and insecure versions of the protocol run on the same 122 port. The client connects to the server, both discover each others' 123 capabilities, and start security negotiations if desired. This method 124 usually requires some changes in the protocol being secured so that 125 it can support the upward negotiation. There is also a high handshake 126 overhead involved in this method. 128 3.1 The COPS/TLS approach 130 COPS/TLS uses a combination of both these approaches to achieve 131 simultaneous operation with COPS/TCP. Initially, the authors had 132 hoped to use the Separate Ports strategy for implementing COPS/TLS, 133 however, due to the reluctance of the IESG to assign a well-known 134 port, they settled on the following approach. 136 When the COPS/TLS server is initialized, it SHOULD bind to any non- 137 well-known port of its choice. The standard COPS server running over 138 TCP MUST know the TCP port on which COPS/TLS is running. How this is 139 achieved is outside the scope of this document. 141 The system acting as the PEP also acts as the TLS client. It needs to 142 first connect to the COPS/TCP server, from where it can be redirected 143 to the COPS/TLS server. 145 3.2 Object Format and Error Codes 147 This section describes the ClientSI object sent in the ClientOpen 148 message and the error codes the server returns. 150 3.2.1 The ClientSI object format 152 0 1 2 3 153 +----------+----------+----------+----------+ 154 | Length (Octets) | C-Num=9 | C-Type=2 | 155 +----------+----------+----------+----------+ 156 | Protocol | Flags | 157 +----------+----------+----------+----------+ 158 | : : : | 159 // : : : // 160 +----------+----------+----------+----------+ 161 | Protocol | Flags | 162 +----------+----------+----------+----------+ 164 Protocol: 165 1 = TLS 167 Flags: 168 0 = Protocol Support Optional 169 1 = Protocol Support Required 171 This ClientSI object MUST be included with the ClientOpen message 172 (Client Type = 0) when the client supports security. For each 173 supported protocol, there MUST be a 32 bit Protocol+Flags pair 174 appended to the object. At present, only one protocol (TLS) is 175 described. However, the ClientSI object definition is general enough 176 to allow addition of new protocols in the future. 178 If multiple protocols are supported by the client, it MUST ensure 179 that no more than one has the 'Protocol Support Required' flag set. 180 Note that it is also valid to mark all protocols as optional. 182 3.2.2 Error Codes and Sub-Codes 184 This section adds to, and modifies, the error codes described in 185 section 2.2.8 (Error Object) of [COPS]. 187 Error Code: 12 = Redirect to Preferred Server: 188 Sub-code: 189 0 = Regular redirect (no security necessary) 190 1 = Use TLS 191 Error Code: 16 = Security Failure 192 17 = Security Required 194 A new error sub-code has been added to the pre-existing error code 195 12. The sub-code informs the client that it SHOULD use TLS when 196 connecting to the redirected server. In the future, more sub-codes 197 may be added to specify additional protocols. 199 Error Code 17 MAY be used by either Client or Server if they require 200 security but the other side doesn't support it. 202 4 Usage Scenarios 204 When the client needs to open a secure connection with the server, it 205 SHOULD first connect to the non-secure port, and send a Client Open 206 message with a ClientType=0. Included in this message, MUST be a 207 ClientSI object, which lists the security capabilities of the client. 208 The following scenarios occur: 210 4.1 Security Required By Client and Server 212 If the server's internal policies allow the client to connect, the 213 server MUST send a ClientClose message with a Redirect object, 214 redirecting the client to the COPS/TLS secure port. Additionally, the 215 error object included in the ClientClose message MUST have the error 216 code = 12 and sub code = 1. 218 If the server's internal policies do not allow the client to connect, 219 the server MUST send a ClientClose with an appropriate error code. 221 4.2 Security Required By Client and Optional on Server 223 If the server's internal policies allow the client to connect 224 securely, the server MUST send a ClientClose message with a Redirect 225 object, redirecting the client to the COPS/TLS secure port. 226 Additionally, the error object included in the ClientClose message 227 MUST have the error code = 12 and sub code = 1. 229 If the server's internal policies do not allow the client to connect 230 securely, the server MUST send a ClientClose with error code 16 or 231 another more appropriate error code. 233 4.3 Security Optional on Client and Required on Server 235 Depending upon its internal policies, the server MAY send a 236 ClientClose message with a Redirect object, redirecting the client to 237 the COPS/TLS secure port. 239 4.4 Security Optional on Client and Server 241 Depending upon its internal policies, the server MAY send a 242 ClientClose message with a Redirect object, redirecting the client to 243 the COPS/TLS secure port. 245 Optionally, the server MAY proceed to establish an insecure 246 connection over COPS/TCP. 248 4.5 Security Supported by Client but not by Server 250 If the Client's capabilities specify that security is optional, the 251 server MAY proceed to establish an insecure connection. Otherwise, it 252 MUST send a ClientClose with the error code 16. 254 4.6 Security supported by Server but not by Client 256 If security is required by the server it MUST send a ClientClose with 257 the error code 16. If security is optional on the server, it MAY 258 establish an insecure connection with the client. 260 4.7 Security not Supported by either Client or Server 262 This is the regular COPS/TCP case as described in [COPS]. In this 263 case, only an insecure connection is possible. 265 5 Secure Connection Initiation 267 Once the PEP receives a redirect from the COPS/TCP server, it 268 initiates a connection to the PDP to the secure COPS port. When this 269 succeeds, the PEP system sends the TLS ClientHello to begin the TLS 270 handshake. When the TLS handshake completes, the PEP MAY initiate the 271 first COPS message. All COPS data MUST be sent as TLS "application 272 data". Normal COPS behavior follows. 274 All PEP implementations of COPS/TLS MUST support an access control 275 mechanism to identify authorized PDPs. This requirement provides a 276 level of assurance that the policy arriving at the PEP is actually 277 valid. The access control mechanism implemented is outside the scope 278 of this document. PEP implementations SHOULD require the use of this 279 access control mechanism for operation of COPS over TLS. When access 280 control is enabled, the PEP implementation MUST NOT initiate COPS/TLS 281 connections to systems not authorized as PDPs by the access control 282 mechanism. 284 Similarly, PDP COPS/TLS implementations MUST support an access 285 control mechanism permitting them to restrict their services to 286 authorized PEP systems only. However, implementations MUST NOT 287 require the use of an access control mechanism at the PDP, as 288 organizations might not consider the types of policy being deployed 289 as sensitive, and therefore do not need to incur the expense of 290 managing credentials for the PEP systems. If access controls are 291 used, however, the PDP implementation MUST terminate COPS/TLS 292 connections from unauthorized PEP systems and log an error if an 293 auditable logging mechanism is present. 295 6 Connection Closure 297 TLS provides facilities to securely close its connections. Reception 298 of a valid closure alert assures an implementation that no further 299 data will arrive on that connection. The TLS specification requires 300 TLS implementations to initiate a closure alert exchange before 301 closing a connection. It also permits TLS implementations to close 302 connections without waiting to receive closure alerts from the peer, 303 provided they send their own first. A connection closed in this way 304 is known as an "incomplete close". TLS allows implementations to 305 reuse the session in this case, but COPS/TLS makes no use of this 306 capability. 308 A connection closed without first sending a closure alert is known as 309 a "premature close". Note that a premature close does not call into 310 question the security of the data already received, but simply 311 indicates that subsequent data might have been truncated. Because TLS 312 is oblivious to COPS message boundaries, it is necessary to examine 313 the COPS data itself (specifically the Message header) to determine 314 whether truncation occurred. 316 6.1. PEP System Behavior 318 PEP implementations MUST treat premature closes as errors and any 319 data received as potentially truncated. The COPS protocol allows the 320 PEP system to find out whether truncation took place. A PEP system 321 detecting an incomplete close SHOULD recover gracefully. 323 PEP systems MUST send a closure alert before closing the connection. 324 Clients unprepared to receive any more data MAY choose not to wait 325 for the PDP system's closure alert and simply close the connection, 326 thus generating an incomplete close on the PDP side. 328 6.2. PDP System Behavior 330 COPS permits a PEP to close the connection at any time, and requires 331 PDPs to recover gracefully. In particular, PDPs SHOULD be prepared to 332 receive an incomplete close from the PEP, since a PEP often shuts 333 down for operational reasons unrelated to the transfer of policy 334 information between the PEP and PDP. 336 Implementation note: The PDP ordinarily expects to be able to 337 signal end of data by closing the connection. However, the PEP 338 may have already sent the closure alert and dropped the 339 connection. 341 PDP systems MUST attempt to initiate an exchange of closure alerts 342 with the PEP system before closing the connection. PDP systems MAY 343 close the connection after sending the closure alert, thus generating 344 an incomplete close on the PEP side. 346 7 Port Number 348 The first data a PDP expects to receive from the PEP is a Client-Open 349 message. The first data a TLS server (and hence a COPS/TLS server) 350 expects to receive is the ClientHello. Consequently, COPS/TLS runs 351 over a separate port in order to distinguish it from COPS alone. When 352 COPS/TLS runs over a TCP/IP connection, the TCP port is any non-well- 353 known port of the PDP's choice. This port MUST be communicated to the 354 COPS/TCP server running on the well-known COPS TCP port. The PEP may 355 use any TCP port. This does not preclude COPS/TLS from running over 356 another transport. TLS only presumes a reliable connection-oriented 357 data stream. 359 8 Endpoint Identification and Access Control 361 Implementations of COPS/TLS MUST use X.509 v3 certificates conforming 362 to [PKIX] to identify PDP and PEP systems. COPS/TLS systems MUST 363 perform certificate verification processing conforming to [PKIX]. 365 If a subjectAltName extension of type dNSName or iPAddress is present 366 in the PDP's certificate, that MUST be used as the PDP identity. 367 Otherwise, the most specific Common Name field in the Subject field 368 of the certificate MUST be used. 370 Matching is performed using the matching rules specified by [PKIX]. 371 If more than one identity of a given type is present in the 372 certificate (e.g. more than one dNSName name, a match in any one of 373 the set is considered acceptable.), the COPS system uses the first 374 name to match, except as noted below in the IP address checking 375 requirements. Names may contain the wildcard character * which is 376 considered to match any single domain name component or component 377 fragment. For example, *.a.com matches foo.a.com but not 378 bar.foo.a.com. f*.com matches foo.com but not foo.bar.com. 380 8.1 PDP Identity 382 Generally, COPS/TLS requests are generated by the PEP consulting 383 bootstrap policy information identifying authorized PDPs. As a 384 consequence, the hostname or IP address for the PDP is known to the 385 PEP. How this bootstrap policy information arrives at the PEP is 386 outside the scope of this document. However, all PEP implementations 387 MUST provide a mechanism to securely deliver or configure the 388 bootstrap policy. In particular, all PEP implementations MUST support 389 a mechanism to securely acquire the signing certificate of the 390 authorized certificate authorities issuing PDP certificates, and MUST 391 support a mechanism to securely acquire an access control list or 392 filter identifying its set of authorized PDPs. 394 PEP implementations that participate in multiple domains, such as 395 those on mobile platforms, MAY use different certificate authorities 396 and access control lists in each domain. 398 Organizations may choose to deliver some or all of the bootstrap 399 policy configuration from an untrusted source, such as DHCP. In this 400 circumstance, COPS over TLS provides no protection from attack when 401 this untrusted source is compromised. 403 If the PDP hostname or IP address is available via the access control 404 mechanism, 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 8.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 authority, 429 and COPS over TLS uses one-way authentication, of the PDP to the PEP. 431 When PEP systems are access controlled, PEPs must be PKI clients in 432 the sense of [PKIX]. In this case, COPS over TLS uses two-way 433 authentication, and the PDP MUST perform the same identity checks for 434 the PEPs as described above for the PDP. 436 When access controls are in effect at the PDP, PDP implementations 437 MUST have a mechanism to securely acquire the signing certificates of 438 the certificate authorities issuing certificates to any of the PEPs 439 they support. 441 9 Other Considerations 443 9.1 Backward Compatibility 444 The client and server SHOULD be backward compatible with peers that 445 do not support security. A client SHOULD be able to handle errors 446 generated by a server which does not understand the ClientSI object 447 mentioned above. Similarly, if a server receives a ClientOpen for 448 Client type=0, which does not contain the ClientSI object, it SHOULD 449 assume that the client wishes to open a non-secure connection and 450 proceed accordingly. 452 9.2 IANA Considerations 454 This draft defines some new error codes and sub codes which require 455 IANA approval. Section 3.2.2 has more details on these codes. 457 10 Security Considerations 459 This entire document concerns security. 461 11 Acknowledgements 463 This document freely plagiarizes and adapts Eric Rescorla's similar 464 document RFC2818 that specifies how HTTP runs over TLS. Discussions 465 with David Durham, Scott Hahn and Ylian Sainte-Hillaire also lead to 466 improvements in this document. 468 12 References 470 [COPS] Durham, D., Boyle, J., Cohen, R., Herzog, R., Rajan, R., 471 Sastry, A., "The COPS (Common Open Policy Service) Protocol", RFC 472 2748, January 200. 474 [PKIX] Housley, R., Ford, W., Polk, W., Solo, D., "Internet Public 475 Key Infrastructure: Part I: X.509 Certificate and CRL Profile", 476 RFC 2459, January 1999. 478 [RFC2026] Bradner, S., "The Internet Standards Process - Revision 479 3", RFC 2026, October 1996 481 [RFC2119] Bradner, S., "Key Words for use in RFCs to indicate 482 Requirement Levels", RFC 2119, March 1997. 484 [TLS] Dierks, T., Allen, C., "The TLS Protocol", RFC2246, January 485 1999. 487 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC2818, May 2000. 489 12 Author Addresses 490 Jesse R. Walker 491 Intel Corporation 492 2111 N.E. 25th Avenue 493 Hillsboro, OR 97214 494 USA 495 jesse.walker@intel.com 497 Amol Kulkarni 498 Intel Corporation 499 JF3-206 500 2111 N.E. 25th Avenue 501 Hillsboro, OR 97214 502 USA 503 amol.kulkarni@intel.com