doc: Add RFC documents

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]
+