summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4261.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4261.txt')
-rw-r--r--doc/rfc/rfc4261.txt787
1 files changed, 787 insertions, 0 deletions
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
+
+
+ <Client-Accept> ::= <Common Header>
+ <KA Timer>
+ [<ACCT Timer>]
+ [<Integrity (C-Num=16, C-Type=2)>]
+
+ 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)
+ <TLS handshake>
+ 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)
+ <TLS handshake>
+ 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]
+