idnits 2.17.1 draft-ietf-rap-cops-tls-03.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 (April 17, 2001) is 8407 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 287, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 290, but no explicit reference was found in the text == Unused Reference: 'RFC2818' is defined on line 296, 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: October 2002 Amol Kulkarni 3 File: draft-ietf-rap-cops-tls-03.txt Intel Corp. 5 COPS Over TLS 7 Last Updated: April 17, 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. However, implementations MUST NOT 111 require the use of an access control mechanism at the PDP, as 112 organizations might not consider the types of policy being deployed 113 as sensitive, and therefore do not need to incur the expense of 114 managing credentials for the PEP systems. If access controls are 115 used, however, the PDP implementation MUST terminate COPS/TLS 116 connections from unauthorized PEP systems and log an error if an 117 auditable logging 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 also permits TLS implementations to close 126 connections without waiting to receive closure alerts from the peer, 127 provided they send their own first. A connection closed in this way 128 is known as an "incomplete close". TLS allows implementations to 129 reuse the session in this case, but COPS/TLS makes no use of this 130 capability. 132 A connection closed without first sending a closure alert is known as 133 a "premature close". Note that a premature close does not call into 134 question the security of the data already received, but simply 135 indicates that subsequent data might have been truncated. Because TLS 136 is oblivious to COPS message boundaries, it is necessary to examine 137 the COPS data itself (specifically the Message header) to determine 138 whether truncation occurred. 140 2.2.1. PEP System Behavior 142 PEP implementations MUST treat premature closes as errors and any 143 data received as potentially truncated. The COPS protocol allows the 144 PEP system to find out whether truncation took place. A PEP system 145 detecting an incomplete close SHOULD recover gracefully. 147 PEP systems MUST send a closure alert before closing the connection. 148 Clients unprepared to receive any more data MAY choose not to wait 149 for the PDP system's closure alert and simply close the connection, 150 thus generating an incomplete close on the PDP side. 152 2.2.2. PDP System Behavior 154 COPS permits a PEP to close the connection at any time, and requires 155 PDPs to recover gracefully. In particular, PDPs SHOULD be prepared to 156 receive an incomplete close from the PEP, since a PEP often shuts 157 down for operational reasons unrelated to the transfer of policy 158 information between the PEP and PDP. 160 Implementation note: The PDP ordinarily expects to be able to 161 signal end of data by closing the connection. However, the PEP 162 may have already sent the closure alert and dropped the 163 connection. 165 PDP systems MUST attempt to initiate an exchange of closure alerts 166 with the PEP system before closing the connection. PDP systems MAY 167 close the connection after sending the closure alert, thus generating 168 an incomplete close on the PEP side. 170 2.3. Port Number 171 The first data a PDP expects to receive from the PEP is a Client-Open 172 message. The first data a TLS server (and hence a COPS/TLS server) 173 expects to receive is the ClientHello. Consequently, COPS/TLS runs 174 over a separate port in order to distinguish it from COPS alone. When 175 COPS/TLS runs over a TCP/IP connection, the default TCP port at the 176 PDP is TBD. The PEP may use any TCP port. This does not preclude 177 COPS/TLS from running over another transport. TLS only presumes a 178 reliable connection-oriented data stream. 180 3. Endpoint Identification and Access Control 182 Implementations of COPS/TLS MUST use X.509 v3 certificates conforming 183 to [PKIX] to identify PDP and PEP systems. COPS/TLS systems MUST 184 perform certificate verification processing conforming to [PKIX]. 186 If a subjectAltName extension of type dNSName or iPAddress is present 187 in the PDP's certificate, that MUST be used as the PDP identity. 188 Otherwise, the most specific Common Name field in the Subject field 189 of the certificate MUST be used. 191 Matching is performed using the matching rules specified by [PKIX]. 192 If more than one identity of a given type is present in the 193 certificate (e.g. more than one dNSName name, a match in any one of 194 the set is considered acceptable.), the COPS system uses the first 195 name to match, except as noted below in the IP address checking 196 requirements. Names may contain the wildcard character * which is 197 considered to match any single domain name component or component 198 fragment. For example, *.a.com matches foo.a.com but not 199 bar.foo.a.com. f*.com matches foo.com but not foo.bar.com. 201 3.1. PDP Identity 203 Generally, COPS/TLS requests are generated by the PEP consulting 204 bootstrap policy information identifying authorized PDPs. As a 205 consequence, the hostname or IP address for the PDP is known to the 206 PEP. How this bootstrap policy information arrives at the PEP is 207 outside the scope of this document. However, all PEP implementations 208 MUST provide a mechanism to securely deliver or configure the 209 bootstrap policy. In particular, all PEP implementations MUST support 210 a mechanism to securely acquire the signing certificate of the 211 authorized certificate authorities issuing PDP certificates, and MUST 212 support a mechanism to securely acquire an access control list or 213 filter identifying its set of authorized PDPs. 215 PEP implementations that participate in multiple domains, such as 216 those on mobile platforms, MAY use different certificate authorities 217 and access control lists in each domain. 219 Organizations may choose to deliver some or all of the bootstrap 220 policy configuration from an untrusted source, such as DHCP. In this 221 circumstance, COPS over TLS provides no protection from attack when 222 this untrusted source is compromised. 224 If the PDP hostname or IP address is available via the access control 225 mechanism, the PEP MUST check it against the PDP's identity as 226 presented in the PDP's TLS Certificate message. 228 In some cases the bootstrap policy will identify the authorized PDP 229 only by an IP address of the PDP system. In this case, the 230 subjectAltName MUST be present in the certificate, and it MUST 231 include an iPAdress format matching the expected name of the policy 232 server. 234 If the hostname of the PDP does not match the identity in the 235 certificate, a PEP on a user oriented system MUST either notify the 236 user (PEP systems MAY afford the user the opportunity to continue 237 with the connection in any case) or terminate the connection with a 238 bad certificate error. PEPs on unattended systems MUST log the error 239 to an appropriate audit log (if available) and MUST terminate the 240 connection (with a bad certificate error). Unattended PEP systems MAY 241 provide a configuration setting that disables this check, but then 242 MUST provide a setting which enables it. 244 3.2. PEP Identity 246 When PEP systems are not access controlled, the PDP need have no 247 external knowledge of what the PEP's identity ought to be and so 248 checks are neither possible nor necessary. In this case, there is no 249 requirement for PEP systems to register with a certificate authority, 250 and COPS over TLS uses one-way authentication, of the PDP to the PEP. 252 When PEP systems are access controlled, PEPs must be PKI clients in 253 the sense of [PKIX]. In this case, COPS over TLS uses two-way 254 authentication, and the PDP MUST perform the same identity checks for 255 the PEPs as described above for the PDP. 257 When access controls are in effect at the PDP, PDP implementations 258 MUST have a mechanism to securely acquire the signing certificates of 259 the certificate authorities issuing certificates to any of the PEPs 260 they support. 262 4. IANA Considerations 264 COPS over TLS uses a separate TCP port from COPS. IANA should assign 265 the value TBD to this port. 267 5. Security Considerations 269 This entire document concerns security. 271 6. Acknowledgements 272 This document freely plagiarizes and adapts Eric Rescorla's similar 273 document RFC2818 that specifies how HTTP runs over TLS. Discussions 274 with David Durham and Ylian Sainte-Hillaire also lead to improvements 275 in this document. 277 7. References 279 [COPS] Durham, D., Boyle, J., Cohen, R., Herzog, R., Rajan, R., 280 Sastry, A., "The COPS (Common Open Policy Service) Protocol", RFC 281 2748, January 200. 283 [PKIX] Housley, R., Ford, W., Polk, W., Solo, D., "Internet Public 284 Key Infrastructure: Part I: X.509 Certificate and CRL Profile", 285 RFC 2459, January 1999. 287 [RFC2026] Bradner, S., "The Internet Standards Process - Revision 288 3", RFC 2026, October 1996 290 [RFC2119] Bradner, S., "Key Words for use in RFCs to indicate 291 Requirement Levels", RFC 2119, March 1997. 293 [TLS] Dierks, T., Allen, C., "The TLS Protocol", RFC2246, January 294 1999. 296 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC2818, May 2000. 298 8. Author Addresses 300 Jesse R. Walker 301 Intel Corporation 302 2111 N.E. 25th Avenue 303 Hillsboro, OR 97214 304 USA 305 jesse.walker@intel.com 307 Amol Kulkarni 308 Intel Corporation 309 JF3-206 310 2111 N.E. 25th Avenue 311 Hillsboro, OR 97214 312 USA 313 amol.kulkarni@intel.com