idnits 2.17.1 draft-ietf-rap-cops-tls-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 "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 (May 23, 2003) is 7644 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) ** Obsolete normative reference: RFC 2459 (Obsoleted by RFC 3280) ** 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 (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Jesse Walker 2 Expiration: November 2003 Amol Kulkarni 3 File: draft-ietf-rap-cops-tls-06.txt Intel Corp. 5 COPS Over TLS 7 Last Updated: May 23, 2003 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 21 documents at any time. It is inappropriate to use Internet-Drafts 22 as reference material or to cite them other than as "work in 23 progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Conventions used in this document 33 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 34 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 35 this document are to be interpreted as described in [RFC2119]. 37 Abstract 39 This memo describes how to use TLS to secure COPS connections over 40 the Internet. 42 Please send comments on this document to the rap@ops.ietf.org 43 mailing list. 45 Table Of Contents 46 1 Introduction...................................................3 47 2 COPS Over TLS..................................................3 48 3 Separate Ports versus Upward Negotiation.......................3 49 3.1 The COPS/TLS approach.........................................4 50 3.2.1 The ClientSI object format..................................4 51 3.2.2 Error Codes and Sub-Codes...................................5 52 4 Usage Scenarios................................................5 53 4.1 Security Mandatory on both, Client and Server.................6 54 4.2 Security Mandatory on Client and Optional on Server...........6 55 4.3 Security Optional on Client and Mandatory on Server...........6 56 4.4 Security Optional on both, Client and Server..................6 57 4.5 Security Mandatory on Client but not supported by Server......6 58 4.6 Security Optional on Client but not supported by Server.......6 59 4.7 Security Mandatory on Server but not supported by Client......6 60 4.8 Security Optional on Server but not supported by Client.......6 61 5 Secure Connection Initiation...................................7 62 6 Connection Closure.............................................7 63 6.1. PEP System Behavior.........................................7 64 6.2. PDP System Behavior.........................................8 65 7 Port Number....................................................8 66 8 Endpoint Identification and Access Control.....................8 67 8.1 PDP Identity.................................................9 68 8.2 PEP Identity................................................10 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......................................11 77 13 Author Addresses..............................................11 79 1 Introduction 81 COPS [RFC2748] was designed to distribute clear-text policy 82 information from a centralized Policy Decision Point (PDP) to a set 83 of Policy Enforcement Points (PEP) in the Internet. COPS provides 84 its own security mechanisms to protect the per-hop integrity of the 85 deployed policy. However, the use of COPS for sensitive applications 86 such as some types of security policy distribution requires 87 additional security measures, such as data privacy. This is because 88 some 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 [RFC2246] 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 During the initial negotiation with the COPS/TCP server, the Message 150 Integrity Object MUST be used to authenticate the validity of the 151 COPS messages. The use of the integrity object is described in 152 [RFC2748]. How the keys indicated by the Integrity Object are shared 153 between the Client and Server is outside the scope of this document. 155 3.2 Object Format and Error Codes 157 This section describes the ClientSI object sent in the ClientOpen 158 message and the error codes the server returns. 160 3.2.1 The ClientSI object format 162 0 1 2 3 163 +----------+----------+----------+----------+ 164 | Length (Octets) | C-Num=9 | C-Type=2 | 165 +----------+----------+----------+----------+ 166 | Protocol | Flags | 167 +----------+----------+----------+----------+ 168 | : : : | 169 // : : : // 170 +----------+----------+----------+----------+ 171 | Protocol | Flags | 172 +----------+----------+----------+----------+ 174 Protocol: 175 1 = TLS 177 Flags: 178 0 = Protocol Support Optional 179 1 = Protocol Support Required 181 This ClientSI object MUST be included with the ClientOpen message 182 (Client Type = 0) when the client supports security. For each 183 supported protocol, there MUST be a 32 bit Protocol+Flags pair 184 appended to the object. At present, only one protocol (TLS) is 185 described. However, the ClientSI object definition is general enough 186 to allow addition of new protocols in the future. 187 If multiple protocols are supported by the client, it MUST ensure 188 that no more than one has the 'Protocol Support Required' flag set. 189 Note that it is also valid to mark all protocols as optional. 191 3.2.2 Error Codes and Sub-Codes 193 This section adds to, and modifies, the error codes described in 194 section 2.2.8 (Error Object) of [RFC2748]. 196 Error Code: 12 = Redirect to Preferred Server: 197 Sub-code: 198 0 = Regular redirect (no security necessary) 199 1 = Use TLS 200 Error Code: 16 = Security Failure 201 17 = Security Required 203 A new error sub-code has been added to the pre-existing error code 204 12. The sub-code informs the client that it SHOULD use TLS when 205 connecting to the redirected server. In the future, more sub-codes 206 may be added to specify additional protocols. 208 Error Code 17 SHOULD be used by either Client or Server if they 209 require security but the other side doesn't support it. 211 4 Usage Scenarios 213 When the client needs to open a secure connection with the server, 214 it SHOULD first connect to the non-secure port, and send a Client 215 Open message with a ClientType=0. 217 The policies implemented on the client dictate whether security is 218 mandatory or optional. 220 If the policies specify that security is mandatory, the above- 221 mentioned ClientSI object MUST be included in the Client Open 222 message. This object MUST list one protocol as required by setting 223 the corresponding flag to 1. 225 If the policies do not explicitly specify that a secure connection 226 is required, the client SHOULD include the ClientSI object, listing 227 protocol support as optional. 229 Note that if the client's policies specifically prohibit a secure 230 connection, it MAY attempt to establish a non-secure connection. 232 Based on the client's policies and the server's policy requirements 233 for the client, the following scenarios occur: 235 4.1 Security Mandatory on both, Client and Server 237 The server MUST send a ClientClose message with a Redirect object, 238 redirecting the client to the COPS/TLS secure port. Additionally, 239 the error object included in the ClientClose message MUST have the 240 error code = 12 and sub code = 1. 242 4.2 Security Mandatory on Client and Optional on Server 244 The server SHOULD send a ClientClose message with a Redirect object, 245 redirecting the client to the COPS/TLS secure port. Additionally, 246 the error object included in the ClientClose message MUST have the 247 error code = 12 and sub code = 1. 249 If the server does not redirect the client to the secure port, it 250 MUST send a ClientClose with the error code 16. 252 4.3 Security Optional on Client and Mandatory on Server 254 The server MUST send a ClientClose message with a Redirect object, 255 redirecting the client to the COPS/TLS secure port. Additionally, 256 the error object included in the ClientClose message MUST have the 257 error code = 12 and sub code = 1. 259 4.4 Security Optional on both, Client and Server 261 The server SHOULD send a ClientClose message with a Redirect object, 262 redirecting the client to the COPS/TLS secure port. Additionally, 263 the error object included in the ClientClose message MUST have the 264 error code = 12 and sub code = 1. 266 Optionally, the server MAY proceed to establish an insecure 267 connection over COPS/TCP. 269 4.5 Security Mandatory on Client but not supported by Server 271 The server MUST send a ClientClose with the error code 16. 273 4.6 Security Optional on Client but not supported by Server 275 The server SHOULD attempt to establish a non-secure connection with 276 the client. 278 4.7 Security Mandatory on Server but not supported by Client 280 If security is required by the server it MUST send a ClientClose 281 with the error code 16. 283 4.8 Security Optional on Server but not supported by Client 285 The server it MAY attempt to establish a non-secure connection with 286 the client. 288 5 Secure Connection Initiation 290 Once the PEP receives a redirect from the COPS/TCP server, it 291 initiates a connection to the PDP to the secure COPS port. When this 292 succeeds, the PEP system sends the TLS ClientHello to begin the TLS 293 handshake. When the TLS handshake completes, the PEP MAY initiate 294 the first COPS message. All COPS data MUST be sent as TLS 295 "application data". Normal COPS behavior follows. 297 All PEP implementations of COPS/TLS MUST support an access control 298 mechanism to identify authorized PDPs. This requirement provides a 299 level of assurance that the policy arriving at the PEP is actually 300 valid. The access control mechanism implemented is outside the scope 301 of this document. PEP implementations SHOULD require the use of this 302 access control mechanism for operation of COPS over TLS. When access 303 control is enabled, the PEP implementation MUST NOT initiate 304 COPS/TLS connections to systems not authorized as PDPs by the access 305 control mechanism. 307 Similarly, PDP COPS/TLS implementations MUST support an access 308 control mechanism permitting them to restrict their services to 309 authorized PEP systems only. However, implementations MUST NOT 310 require the use of an access control mechanism at the PDP, as 311 organizations might not consider the types of policy being deployed 312 as sensitive, and therefore do not need to incur the expense of 313 managing credentials for the PEP systems. If access controls are 314 used, however, the PDP implementation MUST terminate COPS/TLS 315 connections from unauthorized PEP systems and log an error if an 316 auditable logging mechanism is present. 318 6 Connection Closure 320 TLS provides facilities to securely close its connections. Reception 321 of a valid closure alert assures an implementation that no further 322 data will arrive on that connection. The TLS specification requires 323 TLS implementations to initiate a closure alert exchange before 324 closing a connection. It also permits TLS implementations to close 325 connections without waiting to receive closure alerts from the peer, 326 provided they send their own first. A connection closed in this way 327 is known as an "incomplete close". TLS allows implementations to 328 reuse the session in this case, but COPS/TLS makes no use of this 329 capability. 331 A connection closed without first sending a closure alert is known 332 as a "premature close". Note that a premature close does not call 333 into question the security of the data already received, but simply 334 indicates that subsequent data might have been truncated. Because 335 TLS is oblivious to COPS message boundaries, it is necessary to 336 examine the COPS data itself (specifically the Message header) to 337 determine whether truncation occurred. 339 6.1. PEP System Behavior 340 PEP implementations MUST treat premature closes as errors and any 341 data received as potentially truncated. The COPS protocol allows the 342 PEP system to find out whether truncation took place. A PEP system 343 detecting an incomplete close SHOULD recover gracefully. 345 PEP systems MUST send a closure alert before closing the connection. 346 Clients unprepared to receive any more data MAY choose not to wait 347 for the PDP system's closure alert and simply close the connection, 348 thus generating an incomplete close on the PDP side. 350 6.2. PDP System Behavior 352 COPS permits a PEP to close the connection at any time, and requires 353 PDPs to recover gracefully. In particular, PDPs SHOULD be prepared 354 to receive an incomplete close from the PEP, since a PEP often shuts 355 down for operational reasons unrelated to the transfer of policy 356 information between the PEP and PDP. 358 Implementation note: The PDP ordinarily expects to be able to 359 signal end of data by closing the connection. However, the PEP 360 may have already sent the closure alert and dropped the 361 connection. 363 PDP systems MUST attempt to initiate an exchange of closure alerts 364 with the PEP system before closing the connection. PDP systems MAY 365 close the connection after sending the closure alert, thus 366 generating an incomplete close on the PEP side. 368 7 Port Number 370 The first data a PDP expects to receive from the PEP is a Client- 371 Open message. The first data a TLS server (and hence a COPS/TLS 372 server) expects to receive is the ClientHello. Consequently, 373 COPS/TLS runs over a separate port in order to distinguish it from 374 COPS alone. When COPS/TLS runs over a TCP/IP connection, the TCP 375 port is any non-well-known port of the PDP's choice. This port MUST 376 be communicated to the COPS/TCP server running on the well-known 377 COPS TCP port. The PEP may use any TCP port. This does not preclude 378 COPS/TLS from running over another transport. TLS only presumes a 379 reliable connection-oriented data stream. 381 8 Endpoint Identification and Access Control 383 Implementations of COPS/TLS MUST use X.509 v3 certificates 384 conforming to [RFC2459] to identify PDP and PEP systems. COPS/TLS 385 systems MUST perform certificate verification processing conforming 386 to [RFC2459]. In case the Certificate Authority cannot be accessed, 387 communication MAY revert to insecure. 389 If a subjectAltName extension of type dNSName or iPAddress is 390 present in the PDP's certificate, that MUST be used as the PDP 391 identity. Otherwise, the most specific Common Name field in the 392 Subject field of the certificate MUST be used. 394 Matching is performed using the matching rules specified by 395 [RFC2459]. If more than one identity of a given type is present in 396 the certificate (e.g. more than one dNSName name, a match in any one 397 of the set is considered acceptable.), the COPS system uses the 398 first name to match, except as noted below in the IP address 399 checking requirements. Names may contain the wildcard character * 400 which is considered to match any single domain name component or 401 component fragment. For example, *.a.com matches foo.a.com but not 402 bar.foo.a.com. f*.com matches foo.com but not foo.bar.com. 404 8.1 PDP Identity 406 Generally, COPS/TLS requests are generated by the PEP consulting 407 bootstrap policy information identifying authorized PDPs. As a 408 consequence, the hostname or IP address for the PDP is known to the 409 PEP. How this bootstrap policy information arrives at the PEP is 410 outside the scope of this document. However, all PEP implementations 411 MUST provide a mechanism to securely deliver or configure the 412 bootstrap policy. In particular, all PEP implementations MUST 413 support a mechanism to securely acquire the signing certificate of 414 the authorized certificate authorities issuing PDP certificates, and 415 MUST support a mechanism to securely acquire an access control list 416 or filter identifying its set of authorized PDPs. 418 PEP implementations that participate in multiple domains, such as 419 those on mobile platforms, MAY use different certificate authorities 420 and access control lists in each domain. 422 Organizations may choose to deliver some or all of the bootstrap 423 policy configuration from an untrusted source, such as DHCP. In this 424 circumstance, COPS over TLS provides no protection from attack when 425 this untrusted source is compromised. 427 If the PDP hostname or IP address is available via the access 428 control mechanism, the PEP MUST check it against the PDP's identity 429 as presented in the PDP's TLS Certificate message. 431 In some cases the bootstrap policy will identify the authorized PDP 432 only by an IP address of the PDP system. In this case, the 433 subjectAltName MUST be present in the certificate, and it MUST 434 include an iPAdress format matching the expected name of the policy 435 server. 437 If the hostname of the PDP does not match the identity in the 438 certificate, a PEP on a user oriented system MUST either notify the 439 user (PEP systems MAY afford the user the opportunity to continue 440 with the connection in any case) or terminate the connection with a 441 bad certificate error. PEPs on unattended systems MUST log the error 442 to an appropriate audit log (if available) and MUST terminate the 443 connection (with a bad certificate error). Unattended PEP systems 444 MAY provide a configuration setting that disables this check, but 445 then MUST provide a setting which enables it. 447 8.2 PEP Identity 449 When PEP systems are not access controlled, the PDP need have no 450 external knowledge of what the PEP's identity ought to be and so 451 checks are neither possible nor necessary. In this case, there is no 452 requirement for PEP systems to register with a certificate 453 authority, and COPS over TLS uses one-way authentication, of the PDP 454 to the PEP. 456 When PEP systems are access controlled, PEPs must be PKI clients in 457 the sense of [RFC2459]. In this case, COPS over TLS uses two-way 458 authentication, and the PDP MUST perform the same identity checks 459 for the PEPs as described above for the PDP. 461 When access controls are in effect at the PDP, PDP implementations 462 MUST have a mechanism to securely acquire the signing certificates 463 of the certificate authorities issuing certificates to any of the 464 PEPs they support. 466 9 Other Considerations 468 9.1 Backward Compatibility 469 The client and server SHOULD be backward compatible with peers that 470 do not support security. A client SHOULD be able to handle errors 471 generated by a server which does not understand the ClientSI object 472 mentioned above. Similarly, if a server receives a ClientOpen for 473 Client type=0, which does not contain the ClientSI object, it SHOULD 474 assume that the client wishes to open a non-secure connection and 475 proceed accordingly. 477 9.2 IANA Considerations 479 This draft defines some new error codes and sub codes which require 480 IANA approval. Section 3.2.2 has more details on these codes. 482 10 Security Considerations 484 This entire document concerns security. 486 11 Acknowledgements 488 This document freely plagiarizes and adapts Eric Rescorla's similar 489 document [RFC2818] that specifies how HTTP runs over TLS. 490 Discussions with David Durham, Scott Hahn and Ylian Sainte-Hillaire 491 also lead to improvements in this document. 493 12 References 494 12.1 Normative References 496 [RFC2026] Bradner, S., "The Internet Standards Process - Revision 497 3", RFC 2026, October 1996 499 [RFC2119] Bradner, S., "Key Words for use in RFCs to indicate 500 Requirement Levels", RFC 2119, March 1997. 502 [RFC2748] Durham, D., Boyle, J., Cohen, R., Herzog, R., Rajan, 503 R., Sastry, A., "The COPS (Common Open Policy Service) Protocol", 504 RFC 2748, January 200. 506 [RFC2459] Housley, R., Ford, W., Polk, W., Solo, D., "Internet 507 Public Key Infrastructure: Part I: X.509 Certificate and CRL 508 Profile", RFC 2459, January 1999. 510 [RFC2246] Dierks, T., Allen, C., "The TLS Protocol", RFC 2246, 511 January 1999. 513 12.2 Informative References 515 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC2818, May 2000. 517 13 Author Addresses 519 Jesse R. Walker 520 Intel Corporation 521 2111 N.E. 25th Avenue 522 Hillsboro, OR 97214 523 USA 524 jesse.walker[at]intel.com 526 Amol Kulkarni 527 Intel Corporation 528 JF3-206 529 2111 N.E. 25th Avenue 530 Hillsboro, OR 97214 531 USA 532 amol.kulkarni[at]intel.com