From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4261.txt | 787 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 787 insertions(+) create mode 100644 doc/rfc/rfc4261.txt (limited to 'doc/rfc/rfc4261.txt') diff --git a/doc/rfc/rfc4261.txt b/doc/rfc/rfc4261.txt new file mode 100644 index 0000000..3cba66f --- /dev/null +++ b/doc/rfc/rfc4261.txt @@ -0,0 +1,787 @@ + + + + + + +Network Working Group J. Walker +Request for Comments: 4261 A. Kulkarni, Ed. +Updates: 2748 Intel Corp. +Category: Standards Track December 2005 + + + Common Open Policy Service (COPS) + Over Transport Layer Security (TLS) + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + This document describes how to use Transport Layer Security (TLS) to + secure Common Open Policy Service (COPS) connections over the + Internet. + + This document also updates RFC 2748 by modifying the contents of the + Client-Accept message. + + + + + + + + + + + + + + + + + + + + + + +Walker & Kulkarni Standards Track [Page 1] + +RFC 4261 COPS Over TLS December 2005 + + +Table Of Contents + + 1. Introduction ....................................................2 + 2. COPS Over TLS ...................................................3 + 3. Separate Ports versus Upward Negotiation ........................3 + 4. COPS/TLS Objects and Error codes ................................4 + 4.1. The TLS Message Integrity Object (Integrity-TLS) ...........4 + 4.2. Error Codes ................................................4 + 5. COPS/TLS Secure Connection Initiation ...........................5 + 5.1. PEP Initiated Security Negotiation .........................5 + 5.2. PDP Initiated Security Negotiation .........................6 + 6. Connection Closure ..............................................7 + 6.1. PEP System Behavior ........................................7 + 6.2. PDP System Behavior ........................................8 + 7. Endpoint Identification and Access Control ......................8 + 7.1. PEP Identity ...............................................9 + 7.2. PDP Identity ...............................................9 + 8. Cipher Suite Requirements ......................................10 + 9. Backward Compatibility .........................................10 + 10. IANA Considerations ...........................................10 + 11. Security Considerations .......................................11 + 12. Acknowledgements ..............................................11 + 13. References ....................................................12 + 13.1. Normative References .....................................12 + 13.2. Informative References ...................................12 + +1. Introduction + + COPS [RFC2748] was designed to distribute clear-text policy + information from a centralized Policy Decision Point (PDP) to a set + of Policy Enforcement Points (PEP) in the Internet. COPS provides + its own security mechanisms to protect the per-hop integrity of the + deployed policy. However, the use of COPS for sensitive applications + (e.g., some types of security policy distribution) requires + additional security measures, such as data confidentiality. This is + because some organizations find it necessary to hide some or all of + their security policies, e.g., because policy distribution to devices + such as mobile platforms can cross domain boundaries. + + TLS [RFC2246] was designed to provide channel-oriented security. TLS + standardizes SSL and may be used with any connection-oriented + service. TLS provides mechanisms for both one- and two-way + authentication, dynamic session keying, and data stream privacy and + integrity. + + This document describes how to use COPS over TLS. "COPS over TLS" is + abbreviated COPS/TLS. + + + + +Walker & Kulkarni Standards Track [Page 2] + +RFC 4261 COPS Over TLS December 2005 + + +Glossary + + COPS - Common Open Policy Service. See [RFC2748]. + + COPS/TCP - A plain-vanilla implementation of COPS. + + COPS/TLS - A secure implementation of COPS using TLS. + + PDP - Policy Decision Point. Also referred to as the Policy Server. + See [RFC2753]. + + PEP - Policy Enforcement Point. Also referred to as the Policy + Client. See [RFC2753]. + +Conventions used in this document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + +2. COPS Over TLS + + COPS/TLS is very simple: use COPS over TLS similar to how you would + use COPS over TCP (COPS/TCP). Apart from a specific procedure used + to initialize the connection, there is no difference between COPS/TLS + and COPS/TCP. + +3. Separate Ports versus Upward Negotiation + + There are two ways in which insecure and secure versions of the same + protocol can be run simultaneously. + + In the first method, the secure version of the protocol is also + allocated a well-known port. This strategy of having well-known port + numbers for both, the secure and insecure versions, is known as + 'Separate Ports'. The clients requiring security can simply connect + to the well-known secure port. This method is easy to implement, + with no modifications needed to existing insecure implementations. + The disadvantage, however, is that it doesn't scale well, because a + new port is required for each secure implementation. More problems + with this approach have been listed in [RFC2595]. + + The second method is known as 'Upward Negotiation'. In this method, + the secure and insecure versions of the protocol run on the same + port. The client connects to the server, both discover each others' + capabilities, and start security negotiations if desired. This + method usually requires some changes to the protocol being secured. + + + + +Walker & Kulkarni Standards Track [Page 3] + +RFC 4261 COPS Over TLS December 2005 + + + In view of the many issues with the Separate Ports approach, the + authors have decided to use the Upward Negotiation method for + COPS/TLS. + +4. COPS/TLS Objects and Error codes + + This section describes the COPS objects and error codes needed to + support COPS/TLS. + +4.1. The TLS Message Integrity Object (Integrity-TLS) + + The TLS Integrity object is used by the PDP and the PEP to start the + TLS negotiation. This object should be included only in the Client- + Open or Client-Accept messages. It MUST NOT be included in any other + COPS message. + + 0 1 2 3 + + +----------+----------+----------+----------+ + | Length (Octets) | C-Num=16 | C-Type=2 | + +----------+----------+----------+----------+ + | //////// | Flags | + +----------+----------+----------+----------+ + + Note: //// implies the field is reserved, set to 0, and should + be ignored on receipt. + + Flags: 16 bits + 0x01 = StartTLS + This flag indicates that the sender of the message + wishes to initiate a TLS handshake. + + The Client-Type of any message containing this object MUST be 0. + Client-Type 0 is used to negotiate COPS connection level security and + must only be used during the connection establishment phase. Please + refer to section 4.1 of [RFC2748] for more details. + +4.2. Error Codes + + This section uses the error codes described in section 2.2.8 (Error + Object) of [RFC2748]. + + Error Code: 13= Unknown COPS Object: + + + + + + + + +Walker & Kulkarni Standards Track [Page 4] + +RFC 4261 COPS Over TLS December 2005 + + + Sub-code (octet 2) contains the unknown object's C-Num, and (octet 3) + contains unknown object's C-Type. If the PEP or PDP does not support + TLS, the C-Num specified MUST be 16 and the C-Type MUST be 2. This + demonstrates that the TLS version of the Integrity object is not + known. + + This error code MUST be used by either PEP or PDP to indicate a + security-related connection closure if it cannot support a TLS + connection for the COPS protocol. + + If the PDP wishes to negotiate a different security mechanism than + requested by the PEP in the Client-Open, it MUST send the following + error code: + + Error Code: 15= Authentication Required + + Where the Sub-code (octet 2) contains the C-Num=16 value for the + Integrity Object and (octet 3) MUST specify the PDP + required/preferred Integrity object C-Type. If the server does not + support any form of COPS-Security, it MUST set the Sub-code (octet 2) + to 16 and (octet 3) to zero instead, signifying that no type of the + Integrity object is supported. + +5. COPS/TLS Secure Connection Initiation + + Security negotiation may be initiated by either the PDP or the PEP. + The PEP can initiate a negotiation via a Client-Open message, while a + PDP can initiate a negotiation via a Client-Accept message. + + Once the TLS connection is established, all COPS data MUST be sent as + TLS "application data". + +5.1. PEP Initiated Security Negotiation + + A PEP MAY initiate a TLS security negotiation with a PDP using the + Client-Open message. To do this, the Client-Open message MUST have a + Client-Type of 0 and MUST include the Integrity-TLS object. + + Upon receiving the Client-Open message, the PDP SHOULD respond with a + Client-Accept message containing the Integrity-TLS object. + + Note that in order to carry the Integrity-TLS object, the contents of + the Client-Accept message defined in section 3.7 of [RFC2748] need + not change, except that the C-Type of the integrity object contained + there-in should now be C-Type=2. For Example: + + + + + + +Walker & Kulkarni Standards Track [Page 5] + +RFC 4261 COPS Over TLS December 2005 + + + ::= + + [] + [] + + Note also that this new format of the Client-Accept message does not + replace or obsolete the existing Client-Accept message format, which + can continue to be used for non-secure COPS session negotiations. + + Upon receiving the appropriate Client-Accept message, the PEP SHOULD + initiate the TLS handshake. + + The message exchange is as follows: + + C: Client-Open (Client-Type = 0, Integrity-TLS) + S: Client-Accept (Client-Type = 0, Integrity-TLS) + + C/S: <...further messages...> + + In case the PDP does not wish to open a secure connection with the + PEP, it MUST reply with a Client-Close message and close the + connection. The Client-Close message MUST include the error code 15= + Authentication required, with the Sub-code (octet 2) set to 16 for + the Integrity object's C-Num, and (octet 3) set to the C-Type + corresponding to the server's preferred Integrity type, or zero for + no security. + + A PEP requiring the Integrity-TLS object in a Client-Accept message + MUST close the connection if the Integrity-TLS object is missing. + The ensuing Client-Close message MUST include the error code 15= + Authentication required, with the Sub-code (octet 2) containing the + required Integrity object's C-Num=16, and (octet 3) containing the + required Integrity object's C-Type=2. + +5.2. PDP Initiated Security Negotiation + + The PEP initially opens a TCP connection with the PDP on the standard + COPS port and sends a Client-Open message. This Client-Open message + MUST have a Client-Type of 0. + + The PDP SHOULD then reply with a Client-Accept message. In order to + signal the PEP to start the TLS handshake, the PDP MUST include the + Integrity-TLS object in the Client-Accept message. + + Upon receiving the Client-Accept message with the Integrity-TLS + object, the PEP SHOULD initiate the TLS handshake. If for any reason + the PEP cannot initiate the handshake, it MUST close the connection. + + + + +Walker & Kulkarni Standards Track [Page 6] + +RFC 4261 COPS Over TLS December 2005 + + + The message exchange is as follows: + + C: Client-Open (Client-Type = 0) + S: Client-Accept (Client-Type = 0, Integrity-TLS) + + C/S: <...further messages...> + + After receiving the Client-Accept, the PEP MUST NOT send any messages + until the TLS handshake is complete. Upon receiving any message from + the PEP before the TLS handshake starts, the PDP MUST issue a + Client-Close message with an error code 15= Authentication Required. + + A PDP wishing to negotiate security with a PEP having an existing + non-secure connection MUST send a Client-Close with the error code + 15= Authentication required, with the Sub-code (octet 2) containing + the required Integrity object's C-Num=16, and (octet 3) containing + the required Integrity object's C-Type=2, and then wait for the PEP + to reconnect. Upon receiving the Client-Open message, it SHOULD use + the Client-Accept message to initiate security negotiation. + +6. Connection Closure + + TLS provides facilities to securely close its connections. Reception + of a valid closure alert assures an implementation that no further + data will arrive on that connection. The TLS specification requires + TLS implementations to initiate a closure alert exchange before + closing a connection. It also permits TLS implementations to close + connections without waiting to receive closure alerts from the peer, + provided they send their own first. A connection closed in this way + is known as an "incomplete close". TLS allows implementations to + reuse the session in this case, but COPS/TLS makes no use of this + capability. + + A connection closed without first sending a closure alert is known as + a "premature close". Note that a premature close does not call into + question the security of the data already received, but simply + indicates that subsequent data might have been truncated. Because + TLS is oblivious to COPS message boundaries, it is necessary to + examine the COPS data itself (specifically the Message header) to + determine whether truncation occurred. + +6.1. PEP System Behavior + + PEP implementations MUST treat premature closes as errors and any + data received as potentially truncated. The COPS protocol allows the + PEP system to find out whether truncation took place. A PEP system + detecting an incomplete close SHOULD recover gracefully. + + + + +Walker & Kulkarni Standards Track [Page 7] + +RFC 4261 COPS Over TLS December 2005 + + + PEP systems SHOULD send a closure alert before closing the + connection. PEPs unprepared to receive any more data MAY choose not + to wait for the PDP system's closure alert and simply close the + connection, thus generating an incomplete close on the PDP side. + +6.2. PDP System Behavior + + COPS permits a PEP to close the connection at any time, and requires + PDPs to recover gracefully. In particular, PDPs SHOULD be prepared + to receive an incomplete close from the PEP, since a PEP often shuts + down for operational reasons unrelated to the transfer of policy + information between the PEP and PDP. + + Implementation note: The PDP ordinarily expects to be able to + signal the end of data by closing the connection. However, the + PEP may have already sent the closure alert and dropped the + connection. + + PDP systems MUST attempt to initiate an exchange of closure alerts + with the PEP system before closing the connection. PDP systems MAY + close the connection after sending the closure alert, thus generating + an incomplete close on the PEP side. + +7. Endpoint Identification and Access Control + + All PEP implementations of COPS/TLS MUST support an access control + mechanism to identify authorized PDPs. This requirement provides a + level of assurance that the policy arriving at the PEP is actually + valid. PEP deployments SHOULD require the use of this access control + mechanism for operation of COPS over TLS. When access control is + enabled, the PEP implementation MUST NOT initiate COPS/TLS + connections to systems not authorized as PDPs by the access control + mechanism. + + Similarly, PDP COPS/TLS implementations MUST support an access + control mechanism permitting them to restrict their services to + authorized PEP systems only. However, deployments MAY choose not to + use an access control mechanism at the PDP, as organizations might + not consider the types of policy being deployed as sensitive, and + therefore do not need to incur the expense of managing credentials + for the PEP systems. If access controls are used, however, the PDP + implementation MUST terminate COPS/TLS connections from unauthorized + PEP systems and log an error if an auditable logging mechanism is + present. + + Implementations of COPS/TLS MUST use X.509 v3 certificates conforming + to [RFC3280] to identify PDP and PEP systems. COPS/TLS systems MUST + perform certificate verification processing conforming to [RFC3280]. + + + +Walker & Kulkarni Standards Track [Page 8] + +RFC 4261 COPS Over TLS December 2005 + + + 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 as the PDP identity. + If neither type is present, the most specific Common Name field in + the Subject field of the certificate SHOULD be used. + + Matching is performed using the matching rules specified by + [RFC3280]. If more than one identity of a given type is present in + the certificate (e.g., more than one dNSName in the subjectAltName + certificate extension), a match in any one of the provided identities + is acceptable. Generally, the COPS system uses the first name for + matching, except as noted below in the IP address checking + requirements. + +7.1. PEP Identity + + When PEP systems are not access controlled, the PDP does not need + external knowledge of what the PEP's identity ought to be and so + checks are neither possible nor necessary. In this case, there is no + requirement for PEP systems to register with a certificate authority, + and COPS over TLS uses one-way authentication, of the PDP to the PEP. + + When PEP systems are access controlled, PEPs MUST be the subjects of + end entity certificates [RFC3280]. In this case, COPS over TLS uses + two-way authentication, and the PDP MUST perform the same identity + checks for the PEPs as described above for the PDP. + + When access controls are in effect at the PDP, PDP implementations + MUST have a mechanism to securely acquire the trust anchor for each + authorized Certification Authority (CA) that issues certificates to + supported PEPs. + +7.2. PDP Identity + + Generally, COPS/TLS requests are generated by the PEP consulting + bootstrap policy information that identifies PDPs that the PEP is + authorized to connect to. This policy provides the PEP with the + hostname or IP address of the PDP. How this bootstrap policy + information arrives at the PEP is outside the scope of this document. + However, all PEP implementations MUST provide a mechanism to securely + deliver or configure the bootstrap policy. + + All PEP implementations MUST be able to securely acquire the trust + anchor for each authorized Certification Authority (CA) that issues + PDP certificates. Also, the PEPs MUST support a mechanism to + securely acquire an access control list (ACL) or filter identifying + the set of authorized PDPs associated with each CA. Deployments must + take care to avoid circular dependencies in accessing trust anchors + + + +Walker & Kulkarni Standards Track [Page 9] + +RFC 4261 COPS Over TLS December 2005 + + + and ACLs. At a minimum, trust anchors and ACLs may be installed + manually. + + PEP deployments that participate in multiple domains, such as those + on mobile platforms, MAY use different CAs and access control lists + in each domain. + + If the PDP hostname or IP address is available via the bootstrap + policy, the PEP MUST check it against the PDP's identity as presented + in the PDP's TLS Certificate message. + + In some cases, the bootstrap policy will identify the authorized PDP + only by an IP address of the PDP system. In this case, the + subjectAltName MUST be present in the certificate, and it MUST + include an iPAddress format matching the expected name of the policy + server. + + If the hostname of the PDP does not match the identity in the + certificate, a PEP on a user-oriented system MUST either notify the + user (PEP systems MAY afford the user the opportunity to continue + with the connection in any case) or terminate the connection with a + bad certificate error. PEPs on unattended systems MUST log the error + to an appropriate audit log (if available) and MUST terminate the + connection with a bad certificate error. Unattended PEP systems MAY + provide a configuration setting that disables this check, but then + MUST provide a setting that enables it. + +8. Cipher Suite Requirements + + Implementations MUST support the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher + suite. All other cipher suites are optional. + +9. Backward Compatibility + + 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. + +10. IANA Considerations + + The IANA has added the following C-Num, C-Type combination for the + Integrity-TLS object to the registry at + http://www.iana.org/assignments/cops-parameters: + + 0x10 0x02 Message Integrity, Integrity-TLS [RFC4261] + + + + + + +Walker & Kulkarni Standards Track [Page 10] + +RFC 4261 COPS Over TLS December 2005 + + + For Client-Type 0, the IANA has added the following Flags value for + the Integrity-TLS object: + + 0x01 = StartTLS + + Further, for Client-Type 0, the IANA has added the following text for + Error Sub-Codes: + + Error Code: 15 + Error Sub-Code: + Octet 2: C-Num of the Integrity object + Octet 3: C-Type of the supported/preferred Integrity object or + Zero. + + Error-Code Error-SubCode Description + Octet 2 Octet 3 + --------------------------------------------------- + 15 16 0 No security + 15 16 2 Integrity-TLS supported/preferred + + Further values for the Flags field and the reserved field can only be + assigned by IETF Consensus rule, as defined in [RFC2434]. + +11. Security Considerations + + A COPS PDP and PEP MUST check the results of the TLS negotiation to + see whether an acceptable degree of authentication and privacy have + been achieved. If the negotiation has resulted in unacceptable + algorithms or key lengths, either side MAY choose to 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, the PEP and PDP bootstrap policy + must specify this, and PEP and PDP implementations should reject + Client-Open or Client-Accept messages that fail to include an + Integrity-TLS object. + +12. Acknowledgements + + This document freely plagiarizes and adapts Eric Rescorla's similar + document [RFC2818] that specifies how HTTP runs over TLS. + + Discussions with David Durham, Scott Hahn, and Ylian Sainte-Hillaire + also lead to improvements in this document. + + The authors wish to thank Uri Blumenthal for doing a thorough + security review of the document. + + + +Walker & Kulkarni Standards Track [Page 11] + +RFC 4261 COPS Over TLS December 2005 + + +13. References + +13.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2748] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R., + and A. Sastry, "The COPS (Common Open Policy Service) + Protocol", RFC 2748, January 2000. + + [RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework + for Policy-based Admission Control", RFC 2753, January + 2000. + + [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet + X.509 Public Key Infrastructure Certificate and Certificate + Revocation List (CRL) Profile", RFC 3280, April 2002. + + [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", + RFC 2246, January 1999. + +13.2. Informative References + + [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. + + [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, + June 1999. + + [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 2434, + October 1998. + + + + + + + + + + + + + + + + + + + +Walker & Kulkarni Standards Track [Page 12] + +RFC 4261 COPS Over TLS December 2005 + + +Authors' Addresses + + Amol Kulkarni + Intel Corporation + 2111 N.E. 25th Avenue + Hillsboro, OR 97214 + USA + + EMail: amol.kulkarni@intel.com + + + Jesse R. Walker + Intel Corporation + 2111 N.E. 25th Avenue + Hillsboro, OR 97214 + USA + + EMail: jesse.walker@intel.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Walker & Kulkarni Standards Track [Page 13] + +RFC 4261 COPS Over TLS December 2005 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2005). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Walker & Kulkarni Standards Track [Page 14] + -- cgit v1.2.3