idnits 2.17.1 draft-ietf-rap-cops-tls-01.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 (September 7, 2001) is 8260 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 285, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 288, 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) Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Jesse Walker 2 Expiration: March 2002 Amol Kulkarni 3 File: draft-ietf-rap-cops-tls-01.txt Intel Corp. 5 COPS Over TLS 7 Last Updated: September 7, 2001 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 46 1. Introduction...................................................3 47 2. COPS Over TLS..................................................3 48 2.1. Connection Initiation........................................3 49 2.2. Connection Closure...........................................4 50 2.2.1. PEP System Behavior........................................4 51 2.2.2. PDP System Behavior........................................4 52 2.3. Port Number..................................................5 53 3. Endpoint Identification and Access Control.....................5 54 3.1. PDP Identity.................................................5 55 3.2. PEP Identity.................................................6 56 4. IANA Considerations............................................6 57 5. Security Considerations........................................6 58 6. Acknowledgements...............................................6 59 7. References.....................................................7 60 8. Author Addresses...............................................7 62 1. Introduction 64 COPS [COPS] was designed to distribute clear-text policy information 65 from a centralized Policy Decision Point (PDP) to a set of Policy 66 Enforcement Points (PEP) in the Internet. COPS provides its own 67 security mechanisms to protect the per-hop integrity of the deployed 68 policy. However, the use of COPS for sensitive applications such as 69 some types of security policy distribution requires additional 70 security measures, such as data privacy. This is because some 71 organizations find it necessary to hide some or all of their security 72 policies, e.g., because policy distribution to devices such as mobile 73 platforms can cross domain boundaries. 75 TLS [TLS] was designed to provide channel-oriented security. TLS 76 standardizes SSL and may be used with any connection-oriented 77 service. TLS provides mechanisms for both one- and two-way 78 authentication, dynamic session keying, and data stream privacy and 79 integrity. 81 This document describes how to use COPS over TLS. "COPS over TLS" is 82 abbreviated COPS/TLS. 84 2. COPS Over TLS 86 COPS/TLS is very simple: use COPS over TLS exactly as you would use 87 COPS over TCP. 89 2.1. Connection Initiation 91 The system acting as the PEP also acts as the TLS client. This system 92 initiates a connection to the PDP to the secure COPS port. When this 93 succeeds, the PEP system sends the TLS ClientHello to begin the TLS 94 handshake. When the TLS handshake completes, the PEP MAY initiate the 95 first COPS message. All COPS data MUST be sent as TLS "application 96 data". Normal COPS behavior follows. 98 All PEP implementations of COPS/TLS MUST support an access control 99 mechanism to identify authorized PDPs. This requirement provides a 100 level of assurance that the policy arriving at the PEP is actually 101 valid. The access control mechanism implemented is outside the scope 102 of this document. PEP implementations SHOULD require the use of this 103 access control mechanism for operation of COPS over TLS. When access 104 control is enabled, the PEP implementation MUST NOT initiate COPS/TLS 105 connections to systems not authorized as PDPs by the access control 106 mechanism. 108 Similarly, PDP COPS/TLS implementations MUST support an access 109 control mechanism permitting them to restrict their services to 110 authorized PEP systems only. Implementations MUST NOT require the use 111 of an access control mechanism at the PDP, however, as organizations 112 might not consider as sensitive the types of policy being deployed, 113 and therefore do not need to incur the expense of managing 114 credentials for the PEP systems. However, if access controls are 115 used, the PDP implementation MUST terminate COPS/TLS connections from 116 unauthorized PEP systems and log an error if an auditable logging 117 mechanism is present. 119 2.2. Connection Closure 121 TLS provides facilities to securely close its connections. Reception 122 of a valid closure alert assures an implementation that no further 123 data will arrive on that connection. The TLS specification requires 124 TLS implementations to initiate a closure alert exchange before 125 closing a connection. It permits TLS implementations to close 126 connections without waiting to receive closure alerts from the peer, 127 provided they send their own first. TLS allows implementations to 128 reuse the session in this case, but COPS/TLS makes no use of this 129 capability. 131 Note that a premature close does not call into question the security 132 of the data already received, but simply indicates that subsequent 133 data might have been truncated. Because TLS is oblivious to COPS 134 message boundaries, it is necessary to examine the COPS data itself 135 (specifically the Message header) to determine whether truncation 136 occurred. 138 2.2.1. PEP System Behavior 140 PEP implementations MUST treat premature closes as errors and any 141 data received as potentially truncated. The COPS protocol allows the 142 PEP system to find out whether truncation took place. A PEP system 143 detecting an incomplete close SHOULD recover gracefully. 145 PEP systems MUST send a closure alert before closing the connection. 146 Clients unprepared to receive any more data MAY choose not to wait 147 for the PDP system's closure alert and simply close the connection, 148 thus generating an incomplete close on the PDP side. 150 2.2.2. PDP System Behavior 152 COPS permits a PEP to close the connection at any time, and requires 153 PDPs to recover gracefully. In particular, PDPs SHOULD be prepared to 154 receive an incomplete close from the PEP, since a PEP often shuts 155 down for operational reasons unrelated to the transfer of policy 156 information between the PEP and PDP. 158 Implementation note: The PDP ordinarily expects to be able to 159 signal end of data by closing the connection. However, the PEP 160 may have already sent the closure alert and dropped the 161 connection. 163 PDP systems MUST attempt to initiate an exchange of closure alerts 164 with the PEP system before closing the connection. PDP systems MAY 165 close the connection after sending the closure alert, thus generating 166 an incomplete close on the PEP side. 168 2.3. Port Number 169 The first data a PDP expects to receive from the PEP is a Client-Open 170 message. The first data a TLS server (and hence a COPS/TLS server) 171 expects to receive is the ClientHello. Consequently, COPS/TLS runs 172 over a separate port in order to distinguish it from COPS alone. When 173 COPS/TLS runs over a TCP/IP connection, the default TCP port at the 174 PDP is TBD. The PEP may use any TCP port. This does not preclude 175 COPS/TLS from running over another transport. TLS only presumes a 176 reliable connection-oriented data stream. 178 3. Endpoint Identification and Access Control 180 Implementations of COPS/TLS MUST use X.509 v3 certificates conforming 181 to [PKIX] to identify PDP and PEP systems. COPS/TLS systems MUST 182 perform certificate verification processing conforming to [PKIX]. 184 If a subjectAltName extension of type dNSName or iPAddress is present 185 in the PDP's certificate, that MUST be used as the PDP identity. 186 Otherwise, the most specific Common Name field in the Subject field 187 of the certificate MUST be used. 189 Matching is performed using the matching rules specified by [PKIX]. 190 If more than one identity of a given type is present in the 191 certificate (e.g. more than one dNSName name, a match in any one of 192 the set is considered acceptable.), the COPS system uses the first 193 name to match, except as noted below in the IP address checking 194 requirements. Names may contain the wildcard character * which is 195 considered to match any single domain name component or component 196 fragment. For example, *.a.com matches foo.a.com but not 197 bar.foo.a.com. f*.com matches foo.com but not bar.com. 199 3.1. PDP Identity 201 Generally, COPS/TLS requests are generated by the PEP consulting 202 bootstrap policy information identifying authorized PDPs. As a 203 consequence, the hostname or IP address for the PDP is known to the 204 PEP. How this bootstrap policy information arrives at the PEP is 205 outside the scope of this document. However, all PEP implementations 206 MUST provide a mechanism to securely deliver or configure the 207 bootstrap policy. In particular, all PEP implementations MUST support 208 a mechanism to securely acquire the signing certificate of the 209 authorized certificate authorities issuing PDP certificates, and MUST 210 support a mechanism to securely acquire an access control list or 211 filter identifying its set of authorized PDPs. 213 PEP implementations that participate in multiple domains, such as 214 those on mobile platforms, MAY use different certificate authorities 215 and access control lists in each domain. 217 Organizations may choose to deliver some or all of the bootstrap 218 policy configuration from an untrusted source, such as DHCP. In this 219 circumstance, COPS over TLS provides no protection from attack when 220 this untrusted source is compromised. 222 If the PDP hostname or IP address is available via the access control 223 mechanism, the PEP MUST check it against the PDP's identity as 224 presented in the PDP's TLS Certificate message. 226 In some cases the bootstrap policy will identify the authorized PDP 227 only by an IP address of the PDP system. In this case, the 228 subjectAltName MUST be present in the certificate, and it MUST 229 include an iPAdress format matching the expected name of the policy 230 server. 232 If the hostname of the PDP does not match the identity in the 233 certificate, a PEP on a user oriented system MUST either notify the 234 user (PEP systems MAY afford the user the opportunity to continue 235 with the connection in any case) or terminate the connection with a 236 bad certificate error. PEPs on unattended systems MUST log the error 237 to an appropriate audit log (if available) and MUST terminate the 238 connection (with a bad certificate error). Unattended PEP systems MAY 239 provide a configuration setting that disables this check, but then 240 MUST provide a setting which enables it. 242 3.2. PEP Identity 244 When PEP systems are not access controlled, the PDP need have no 245 external knowledge of what the PEP's identity ought to be and so 246 checks are neither possible nor necessary. In this case, there is no 247 requirement for PEP systems to register with a certificate authority, 248 and COPS over TLS uses one-way authentication, of the PDP to the PEP. 250 When PEP systems are access controlled, PEPs must be PKI clients in 251 the sense of [PKIX]. In this case, COPS over TLS uses two-way 252 authentication, and the PDP MUST perform the same identity checks for 253 the PEPs as described above for the PDP. 255 When access controls are in effect at the PDP, PDP implementations 256 MUST have a mechanism to securely acquire the signing certificates of 257 the certificate authorities issuing certificates to any of the PEPs 258 they support. 260 4. IANA Considerations 262 COPS over TLS uses a separate TCP port from COPS. IANA should assign 263 the value TBD to this port. 265 5. Security Considerations 267 This entire document concerns security. 269 6. Acknowledgements 270 This document freely plagiarizes and adapts Eric Rescorla's similar 271 document draft-ietf-tls-http-xx.txt that specifies how HTTP runs over 272 TLS. Discussions with David Durham and Ylian Sainte-Hillaire also 273 lead to improvements in this document. 275 7. References 277 [COPS] Durham, D., Boyle, J., Cohen, R., Herzog, R., Rajan, R., 278 Sastry, A., "The COPS (Common Open Policy Service) Protocol", RFC 279 2748, January 200. 281 [PKIX] Housley, R., Ford, W., Polk, W., Solo, D., "Internet Public 282 Key Infrastructure: Part I: X.509 Certificate and CRL Profile", 283 RFC 2459, January 1999. 285 [RFC2026] Bradner, S., "The Internet Standards Process - Revision 286 3", RFC 2026, October 1996 288 [RFC2119] Bradner, S., "Key Words for use in RFCs to indicate 289 Requirement Levels", RFC 2119, March 1997. 291 [TLS] Dierks, T., Allen, C., "The TLS Protocol", RFC2246, January 292 1999. 294 8. Author Addresses 296 Jesse R. Walker 297 Intel Corporation 298 2111 N.E. 25th Avenue 299 Hillsboro, OR 97214 300 USA 301 jesse.walker@intel.com 303 Amol Kulkarni 304 Intel Corporation 305 JF3-206 306 2111 N.E. 25th Avenue 307 Hillsboro, OR 97214 308 USA 309 amol.kulkarni@intel.com