Common Open Policy Service (COPS) Over Transport Layer Security (TLS)
updated by
- rfc-8996 — Deprecating TLS 1.0 and TLS 1.1
updates
- rfc-2748 — The COPS (Common Open Policy Service) Protocol
Extracted elements (24)
COPS/TLS uses Upward Negotiation (both secure and insecure versions share the same port, with capability discovery) rather than Separate Ports, because the Separate Ports approach does not scale well and requires a new port for each secure protocol variant.
COPS/TLS was modeled on RFC 2818 (HTTP Over TLS). The Upward Negotiation approach was selected over Separate Ports because the latter requires a new well-known port per secure protocol variant and does not scale; existing issues with Separate Ports are documented in RFC 2595.
The PEP and PDP SHOULD be backward compatible with peers that have not been modified to support COPS/TLS. They SHOULD handle errors generated in response to the Integrity-TLS object, enabling graceful fallback in mixed deployments.
A PEP initiating TLS negotiation via Client-Open MUST set Client-Type to 0 and MUST include the Integrity-TLS object. A PEP requiring Integrity-TLS in Client-Accept MUST close the connection if the object is missing, sending error code 15 with C-Num=16 and C-Type=2.
After the PEP receives a Client-Accept containing Integrity-TLS (PDP-initiated flow), the PEP MUST NOT send any messages until the TLS handshake completes. If the PDP receives any message from the PEP before the handshake starts, it MUST issue Client-Close with error code 15.
All PEP implementations of COPS/TLS MUST support an access control mechanism to identify authorized PDPs. When access control is enabled, the PEP MUST NOT initiate COPS/TLS connections to systems not authorized as PDPs.
Error Code 13 (Unknown COPS Object, C-Num=16, C-Type=2) MUST be used by either PEP or PDP to indicate a security-related connection closure if it cannot support a TLS connection.
If a subjectAltName extension of type dNSName or iPAddress is present in the PDP's certificate, it MUST be used as the PDP identity. If both types are present, dNSName SHOULD be used. If neither is present, the most specific Common Name SHOULD be used.
If the PDP hostname does not match the certificate identity, a PEP on a user-oriented system MUST either notify the user or terminate with a bad certificate error; unattended PEPs MUST log the error and MUST terminate the connection.
Implementations MUST support the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher suite. All other cipher suites are optional.
Implementations of COPS/TLS MUST use X.509 v3 certificates conforming to RFC 3280 to identify PDP and PEP systems, and MUST perform certificate verification processing per RFC 3280.
Once the TLS connection is established, all COPS data MUST be sent as TLS 'application data'.
PDP systems MUST attempt to initiate an exchange of closure alerts with the PEP before closing the connection. PDPs SHOULD be prepared to receive an incomplete close from the PEP.
PEP implementations MUST treat premature TLS closes (connection closed without closure alert) as errors and treat any data already received as potentially truncated. The COPS message header should be examined to determine whether truncation occurred.
The Integrity-TLS object MUST NOT be included in any COPS message other than Client-Open or Client-Accept. Any message containing this object MUST have a Client-Type of 0.
When the bootstrap policy identifies the PDP only by an IP address, the certificate's subjectAltName MUST be present and MUST include an iPAddress format matching that address.
Error Code 13 (Unknown COPS Object) is used when a PEP or PDP does not support TLS; sub-code octet 2 MUST be 16 (C-Num) and octet 3 MUST be 2 (C-Type). Error Code 15 (Authentication Required) is used when the PDP requires a different or any security mechanism; sub-code octet 2 carries the C-Num=16 and octet 3 carries the required/preferred C-Type, or zero for no security.
The TLS Message Integrity Object (Integrity-TLS) has C-Num=16 and C-Type=2. It is a 8-byte object with a 16-bit reserved field and a 16-bit Flags field; flag 0x01 (StartTLS) indicates the sender wishes to initiate a TLS handshake. It MUST NOT appear in any COPS message other than Client-Open or Client-Accept.
IANA added C-Num=0x10 (16), C-Type=0x02 (2) — 'Message Integrity, Integrity-TLS' — to the COPS Parameters registry. For Client-Type 0, the flag value 0x01=StartTLS was registered for the Integrity-TLS object, and error sub-code values for Error Code 15 (octet 2=16, octet 3=0 for no security; octet 3=2 for Integrity-TLS preferred) were also added.
A COPS PDP and PEP MUST check the results of the TLS negotiation to verify that an acceptable degree of authentication and privacy was achieved; if unacceptable algorithms or key lengths result, either side MAY terminate the connection.
A man-in-the-middle attack can be launched by deleting the Integrity-TLS object or altering the Client-Open or Client-Accept messages. If security is required, bootstrap policy must mandate it and implementations should reject messages that fail to include the Integrity-TLS object.
PDP-initiated TLS negotiation: PEP sends Client-Open (Client-Type=0, no Integrity-TLS); PDP replies with Client-Accept (Client-Type=0, Integrity-TLS); PEP initiates TLS handshake. After receiving Client-Accept with Integrity-TLS, the PEP MUST NOT send any messages until the TLS handshake is complete.
PEP-initiated TLS negotiation: PEP sends Client-Open (Client-Type=0, Integrity-TLS); PDP responds with Client-Accept (Client-Type=0, Integrity-TLS); PEP initiates TLS handshake; subsequent COPS messages flow over TLS. If the PDP refuses, it sends Client-Close with error 15.
The Integrity-TLS object is encoded as: 2-byte Length, 1-byte C-Num=16, 1-byte C-Type=2, 2 reserved bytes (set to 0, ignored on receipt), and a 2-byte Flags field. Flag bit 0x01 signals StartTLS.