Internet Draft                                       Jesse Walker
     Expiration: May 2004 February 2005                       Amol Kulkarni, Ed.
     File: draft-ietf-rap-cops-tls-07.txt draft-ietf-rap-cops-tls-08.txt                  Intel Corp.

                               COPS Over TLS

                         Last Updated: November 24, 2003 August 16, 2004

 Status of this Memo

    This document is an Internet-Draft and is in full conformance with
    all provisions of Section 10 of [RFC2026].

    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF), its areas, and its working groups.  Note that
    other groups may also distribute working documents as Internet-
    Drafts.

    Internet-Drafts are draft documents valid for a maximum of six
    months and may be updated, replaced, or obsoleted by other
    documents at any time.  It is inappropriate to use Internet-Drafts
    as reference material or to cite them other than as "work in
    progress."

    The list of current Internet-Drafts can be accessed at
    http://www.ietf.org/ietf/1id-abstracts.txt

    The list of Internet-Draft Shadow Directories can be accessed at
    http://www.ietf.org/shadow.html.

 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 [RFC2119].

 Abstract

    This memo describes how to use TLS to secure COPS connections over
    the Internet.

    Please send comments on this document to the rap@ops.ietf.org
    mailing list.

 Table Of Contents
    Glossary..........................................................3
    1  Introduction...................................................3
    2  COPS Over TLS..................................................3
    3  Separate Ports versus Upward Negotiation........................3
    3.1 The Negotiation.......................3
    4  COPS/TLS approach.........................................4
    3.2.1 The ClientSI object format..................................5
    3.2.2 Error Codes Objects and Sub-Codes...................................5
    4 Usage Scenarios.................................................6 Error codes...............................4
    4.1 Security Mandatory on both, Client and Server.................6 The StartTLS ClientSI Object..................................4
    4.2 Security Mandatory on Client and Optional on Server...........7
    4.3 Security Optional on Client and Mandatory on Server...........7
    4.4 Security Optional on both, Client and Server..................7
    4.5 Security Mandatory on Client but not supported by Server......7
    4.6 Security Optional on Client but not supported by Server.......7
    4.7 Security Mandatory on Server but not supported by Client......7
    4.8 Security Optional on Server but not supported by Client.......7 Error Codes...................................................4
    5  COPS/TLS Secure Connection Initiation....................................7 Initiation..........................4
    5.1 PDP Initiated Security Negotiation............................4
    5.2 PEP Initiated Security Negotiation............................5
    6  Connection Closure..............................................8
    6.1. Closure.............................................6
    6.1 PEP System Behavior.........................................8
    6.2. Behavior...........................................6
    6.2 PDP System Behavior.........................................9 Behavior...........................................6
    7  Port Number.....................................................9 Number....................................................7
    8  Endpoint Identification and Access Control.....................9 Control.....................7
    8.1 PDP Identity................................................10 Identity..................................................8
    8.2 PEP Identity................................................11 Identity..................................................8
    9 Other Considerations...........................................11
    9.1  Backward Compatibility.......................................11
    9.2 IANA Considerations..........................................11 Compatibility.........................................9
    10  Security Considerations......................................11 IANA Considerations............................................9
    11  Acknowledgements.............................................11 Security Considerations........................................9
    12 References....................................................12
    12.1 Acknowledgements...............................................9
    13 References....................................................10
    13.1 Normative References........................................12
    12.2 References........................................10
    13.2 Informative References......................................12
    13 References......................................10
    14  Author Addresses.............................................12 Addresses.............................................10
    15  Intellectual Property Statement..............................11
    16 Full Copyright Statement......................................11
 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].

 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
    such as some types of security policy distribution requires
    additional security measures, such as data privacy. 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.

 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. The main advantage of this strategy
    is that it This method is very simple easy to implement,
    with no modifications needed to existing insecure implementations. Thus it is the most popular
    approach.
    The disadvantage, however, is that it doesn't scale well, with a new
    port required for each secure implementation. Hence, the
    IESG discourages designers from using the strategy. 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 in to the protocol being secured
    so that it can support the upward negotiation. There is also a high
    handshake overhead involved in this method.

 3.1 The COPS/TLS approach secured.

    COPS/TLS uses a combination of both these approaches to achieve
    simultaneous operation with COPS/TCP. Initially, the authors had
    hoped to use the Separate Ports strategy for implementing COPS/TLS,
    however, due to the reluctance of the IESG Upward Negotiation method to assign a well-known
    port, they settled on the following approach.

    When the secure COPS messages.

 4  COPS/TLS server is initialized, it SHOULD bind Objects and Error codes

    This section describes the COPS objects and error codes needed to any non-
    well-known port of its choice.
    support COPS/TLS.

 4.1 The standard COPS server running over
    TCP MUST know the TCP port on which COPS/TLS is running. How this is
    achieved StartTLS ClientSI Object

    The StartTLS ClientSI object is outside used by the scope of this document.

    The system acting as PDP and the PEP also acts as the TLS client. It needs
    to first connect to start
    the COPS/TCP server, from where it TLS negotiation. This object can be
    redirected to the COPS/TLS server.

    During the initial negotiation with the COPS/TCP server, included either in the Message
    Integrity Object MUST be used to authenticate
    ClientAccept message, or a Request message. Also, the validity ClientType of the
    COPS messages. As specified in [RFC2748], the integrity
    any message containing this ClientSI object
    contains a sequence number, a Key Id and a message digest. The
    sequence number is used to foil replay attacks while the Key Id
    identifies a secret key shared between the client and the server.
    COPS uses the HMAC-MD5-96 algorithm to generate a digest of the
    entire COPS message, up to and including the sequence number and Key
    Id.

    The specifics of key distribution and maintenance are outside the
    scope of this document.

 3.2 Object Format and Error Codes

    This section describes the ClientSI object sent in the ClientOpen
    message and the error codes the server returns.

 3.2.1 The ClientSI object format MUST be 0.

          0         1          2          3
    +----------+----------+----------+----------+
    |    Length (Octets)  | C-Num=9  | C-Type=1 |
    +----------+----------+----------+----------+
    |       Protocol      |        Flags        |
    +----------+----------+----------+----------+
    |          :          :          :          |
    //         :          :          :         //
    +----------+----------+----------+----------+
    |       Protocol       ////////      |        Flags        |
    +----------+----------+----------+----------+

    Protocol:
         1 = TLS

    Flags:
         0 = Protocol Support Optional
         1 = Protocol Support Required

    This ClientSI object MUST be included with the ClientOpen message
    (Client Type = 0) when the client supports security. For each
    supported protocol, there MUST be a 32 bit Protocol+Flags pair
    appended to the object. At present, only one protocol (TLS) is
    described. However, the ClientSI object definition is general enough
    to allow addition of new protocols in the future.

    If multiple protocols are supported by the client, it MUST ensure
    that no more than one has the 'Protocol Support Required' flag set.
    Note that it is also valid to mark all protocols as optional. This
    is used by the client to notify the server that a secure connection
    is not mandatory.

 3.2.2 TLS

 4.2 Error Codes and Sub-Codes

    This section adds to, and modifies, to the error codes described in section 2.2.8
    (Error Object) of [RFC2748].

    Error Code: 12 = Redirect to Preferred Server:
                Sub-code:
                  0 = Regular redirect (no security necessary)
                  1 = Use TLS
    Error Code: 16 = Security Failure
                17 = Security TLS Required

    A new error sub-code has been added to the pre-existing

    This error code
    12. The sub-code informs the client that it SHOULD use TLS when
    connecting to the redirected server. In the future, more sub-codes
    may be added to specify additional protocols.

    Error Code 17 SHOULD should be used by either Client PEP or Server PDP if they require
    security but the other side doesn't support it.

 4 Usage Scenarios

    When the client needs to open a secure connection with

 5  COPS/TLS Secure Connection Initiation

    Security negotiation may be initiated either by the server,
    it SHOULD first connect to PDP or the non-secure port, and send PEP.
    The PDP can initiate a Client
    Open message with a ClientType=0.

    'Bootstrap' policies implemented on the client dictate whether security is mandatory negotiation either via a
    ClientAccept or optional.

    If a ClientClose message, while a PEP can initiate a
    negotiation via a Request message.

    Once the policies specify that security TLS connection is mandatory, the above-
    mentioned ClientSI object established, all COPS data MUST be included in sent
    as TLS "application data".

 5.1 PDP Initiated Security Negotiation
    The PEP initially opens a TCP connection with the Client Open PDP on the
    standard COPS port and sends a ClientOpen message. This object ClientOpen
    message MUST list one protocol as Required by setting have a ClientType of 0.

    The PDP then replies with a ClientAccept. In order to signal the corresponding flag PEP
    to 1.

    If start the policies do not explicitly specify that a secure connection
    is required, TLS handshake, the client SHOULD PDP MUST include the StartTLS
    ClientSI object, listing
    protocol support as Optional. object in the ClientAccept message.

    Note that if the client's policies specifically prohibit a secure
    connection, it MAY attempt in order to establish an insecure connection.

    Based on the client's policies and carry the server's policy requirements
    for StartTLS ClientSI object, the client, a number
    contents of usage scenarios are possible. The figure
    below shows the type ClientAccept message defined in section 3.7 of connections established for the scenarios.
    The sections following
    [RFC2748] need to change to the figure explain following:

    <Client-Accept> ::= <Common Header>
                        <KA Timer>
                        [<ACCT Timer>]
                        [<ClientSI>]
                        [<Integrity>]

    Upon receiving the various scenarios in
    greater detail.

    +---------+------------+------------+-------------+
    |\SERVER  |            |            |             |
    |C\       |            |            | Security    |
    |L \      |  Security  | Security   | Not         |
    |I  \     |  Mandatory | Optional   | Supported   |
    |E   \    |            |            |             |
    |N    \   |            |            |             |
    |T     \  |            |            |             |
    +---------+------------+------------+-------------+
    |Mandatory|  Secure    |  Secure    | Disconnect  |
    +---------+------------+------------+-------------+
    |Optional |  Secure    |  Secure /  | Insecure    |
    |         |            |  Insecure  |             |
    +---------+------------+------------+-------------+
    |Not      |            |            |             |
    |Supported| Disconnect |  Insecure  | Insecure    |
    +---------+------------+------------+-------------+

 4.1 Security Mandatory on both, Client and Server

    The server MUST send a ClientClose ClientAccept message with a Redirect the StartTLS ClientSI
    object,
    redirecting the client to PEP SHOULD initiate the COPS/TLS secure port. Additionally, TLS handshake. If for any reason
    the error object included in PEP cannot initiate the ClientClose message handshake, it MUST have close the
    error code connection.

    The message exchange is as follows:
    C: ClientOpen   (ClientType = 12 and sub code 0)
    S: ClientAccept (ClientType = 1.

 4.2 Security Mandatory on Client and Optional on Server

    The server SHOULD send a ClientClose message with a Redirect object,
    redirecting the client to the COPS/TLS secure port. Additionally, 0, StartTLS)
    <TLS handshake>
    C/S: <...further messages...>

    Until the error object included in TLS handshake is complete the ClientClose message PEP MUST have the
    error code = 12 NOT send any
    messages other than ClientClose and sub code = 1.

    If the server does not redirect the client to the secure port, it KeepAlive. Upon receiving any
    other message, a PDP expecting a TLS negotiation MUST send issue a
    ClientClose message with the an error code of 16.

 4.3

 5.2 PEP Initiated Security Optional on Client and Mandatory Negotiation

    If a PEP wishes to use TLS on Server

    The server an existing non-secure COPS
    connection, it MUST send issue a ClientClose Request message with a Redirect object,
    redirecting the client to the COPS/TLS secure port. Additionally,
    the error ClientType of 0.
    The StartTLS ClientSI object MUST be included in the ClientClose message MUST have request.

    In response, the
    error code = 12 and sub code = 1.

 4.4 Security Optional on both, Client and Server

    The server PDP SHOULD send a ClientClose Decision message with a Redirect object,
    redirecting containing the client to
    appropriate Command-Code (1 = Install/Accept, 2 = Remove/Reject) in
    the COPS/TLS secure port. Additionally, Decision Flags object.

    If the error object included in request is accepted, the ClientClose message PEP MUST have start the
    error code = 12 and sub code = 1.

    Optionally, TLS handshake.
    After the server MAY proceed to establish an insecure
    connection over COPS/TCP.

 4.5 Security Mandatory on Client but not supported by Server

    The server TLS handshake is complete, the PDP MUST send a ClientClose synchronize state
    with the error code 16.

 4.6 Security Optional on Client but not supported by Server PEP.

    The server SHOULD attempt to establish a non-secure connection with
    the client.

 4.7 Security Mandatory on Server but not supported by Client message exchange is as follows:
    <...existing COPS/TCP connection...>
    C: Request   (ClientType = 0, StartTLS)
    S: Decision  (ClientType = 0, Install)
    <TLS handshake>
    S: Synchronize
    If security the PEP's TLS request is required rejected by the server PDP, the PEP MAY choose
    to continue using the non-secure connection. Else, it MUST send close the
    connection by sending a ClientClose message with the an error code of
    16.

 4.8 Security Optional on Server but not supported by Client

    The server it MAY attempt to establish a non-secure connection with
    the client.

 5 Secure Connection Initiation

    Once the PEP receives a redirect from the COPS/TCP server, it
    initiates a connection to the PDP to the secure COPS port. When this
    succeeds, the PEP system sends the TLS ClientHello to begin the TLS
    handshake. When the TLS handshake completes, the PEP MAY initiate
    the first COPS message. All COPS data MUST be sent as TLS
    "application data". Normal COPS behavior follows.

    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 implementations 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, implementations 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.

    Section 8 provides more details on access control.

 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.

 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.

    PEP systems MUST send a closure alert before closing the connection.
    Clients
    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.

 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 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  Port Number

    The first data a PDP expects to receive from the PEP is a Client-
    Open message. The first data a TLS server (and hence a COPS/TLS
    server) PDP)
    expects to receive is the ClientHello. Consequently, COPS/TLS runs
    over a separate port in order to distinguish it from COPS alone.
    When COPS/TLS runs over a TCP/IP connection, the TCP port is any
    non-well-known port of the PDP's choice. This port MUST be
    communicated to the COPS/TCP server PDP running on the well-known COPS TCP
    port. The PEP may use any TCP port. This does not preclude COPS/TLS
    from running over another transport. TLS only presumes a reliable
    connection-oriented data stream.

 8  Endpoint Identification and Access Control

    Implementations

    All PEP implementations of COPS/TLS MUST use X.509 v3 certificates
    conforming to [RFC2459] support an access control
    mechanism to identify PDP and PEP systems. COPS/TLS
    systems authorized PDPs. This requirement provides a
    level of assurance that the policy arriving at the PEP is actually
    valid. PEP implementations SHOULD require the use of this access
    control mechanism for operation of COPS over TLS. When access
    control is enabled, the PEP implementation MUST perform certificate verification processing conforming NOT initiate
    COPS/TLS connections to [RFC2459]. In case the Certificate Authority cannot be accessed, 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, implementations MAY choose not
    to use a Web an access control mechanism at the PDP, as organizations
    might not consider the types of Trust policy being deployed as sensitive,
    and therefore do not need to verify incur the identity,
    or expense of managing
    credentials for the communication MAY revert 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 insecure. [RFC3280].

    If a subjectAltName extension of type dNSName or iPAddress is
    present in the PDP's certificate, it MUST be used as the PDP
    identity. Otherwise, If both types are present, dNSName SHOULD be used as the
    PDP identity. If neither of the types is present, the most specific
    Common Name field in the Subject field of the certificate MUST SHOULD be
    used.

    Matching is performed using the matching rules specified by
    [RFC2459].
    [RFC3280]. If more than one identity of a given type is present in
    the certificate (e.g. more than one dNSName name, name in the
    subjectAltName certificate extension), a match in any one of the set
    provided identities is considered acceptable), acceptable. Generally, the COPS system uses
    the first name to match, for matching, except as noted below in the IP
    address checking requirements. Names may contain the wildcard character * which is
    considered to match any single domain name component or component
    fragment. For example, *.a.com matches foo.a.com but not
    bar.foo.a.com. f*.com matches foo.com but not foo.bar.com.

 8.1 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.

    Organizations MAY choose to deliver some or all of the bootstrap
    policy configuration from an untrusted source, such as DHCP. In this
    circumstance, COPS over TLS provides no protection from attack when
    this untrusted source is compromised.

    All PEP implementations MUST be able to securely acquire the signing
    certificates of authorized Certificate Authorities that issue PDP
    certificates. Also, the PEPs MUST support a mechanism to securely
    acquire an access control list or filter identifying the CA's set of
    authorized PDPs.

    PEP implementations 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 iPAdress 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 which enables it.

 8.2 PEP Identity

    When PEP systems are not access controlled, the PDP need have no
    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 MUST be PKI clients in
    the sense of [RFC2459]. [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 signing certificates
    of the Certificate Authorities issuing certificates to any of the
    PEPs they support.

 9 Other Considerations

 9.1  Backward Compatibility

    The client PEP and server PDP SHOULD be backward compatible with peers that have
    not been modified to support COPS/TLS.

    A client They SHOULD be able to handle errors
    generated by a COPS/TCP
    server which does not understand in response to the StartTLS ClientSI object mentioned
    above. Similarly, if a COPS/TCP server receives object.

    In case a ClientOpen for
    Client type=0, which PEP does not contain start the TLS handshake upon receiving the
    StartTLS ClientSI object, it SHOULD
    assume that the client wishes to open a non-secure connection and
    proceed accordingly.

 9.2 PDP MUST close the connection.

 10 IANA Considerations

    This draft defines some new error codes and sub codes which require

    The IANA approval. Section 3.2.2 has more details on these codes.

 10 shall add the following Error-Code to the cops-parameters
    document:

    Error-Code: 16
    Description: TLS Required

 11 Security Considerations

    This entire document concerns security.

 11

    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 StartTLS
    ClientSI object from the ClientAccept or Request messages. To
    prevent this, the PEP and PDP MUST use the Integrity object as
    defined in [RFC2748].

    A downgrade attack against a PEP requesting TLS negotiation is
    possible by modifying the PDP's Decision message flag to 'Remove'.
    Again, this can be avoided by using the Integrity object as defined
    in [RFC2748].

 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.

 12

 13 References
 12.1
 13.1 Normative References

       [RFC2026] Bradner, S., "The Internet Standards Process - Revision
       3", RFC 2026, October 1996

       [RFC2119] Bradner, S., "Key Words for use in RFCs to indicate
       Requirement Levels", RFC 2119, March 1997.

       [RFC2748] Durham, D., Boyle, J., Cohen, R., Herzog, R., Rajan,
       R., Sastry, A., "The COPS (Common Open Policy Service) Protocol",
       RFC 2748, January 2000.

       [RFC2459]

       [RFC3280] Housley, R., Ford, W., Polk, W., Solo, D., "Internet
       X.509 Public Key Infrastructure: Part I: X.509 Infrastructure Certificate and CRL
       Profile", Certificate
       Revocation List (CRL) Profile ", RFC 2459, January 1999. 3280, April 2002.

       [RFC2246] Dierks, T., Allen, C., "The TLS Protocol", RFC 2246,
       January 1999.

 12.2

 13.2 Informative References

       [RFC2818] Rescorla, E., "HTTP Over TLS", RFC2818, RFC 2818, May 2000.

 13

       [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC
       2595, June 1999.

       [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP
       over Transport Layer Security", RFC 3207, February 2002.

 14  Author Addresses

       Jesse R. Walker
       Intel Corporation
       2111 N.E. 25th Avenue
       Hillsboro, OR  97214
       USA
       jesse.walker[at]intel.com

       Amol Kulkarni
       Intel Corporation
       JF3-206
       2111 N.E. 25th Avenue
       Hillsboro, OR  97214
       USA
       amol.kulkarni[at]intel.com
 15  Intellectual Property Statement

    The IETF takes no position regarding the validity or scope of any
    intellectual property 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; neither does it represent that it
    has made any effort to identify any such rights. Information on the
    IETF's procedures with respect to rights in standards-track and
    standards-related documentation can be found in BCP-11. Copies of
    claims of rights made available for publication 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 implementors or users of this specification
    can be obtained from the IETF Secretariat.

    The IETF invites any interested party to bring to its attention any
    copyrights, patents or patent applications, or other proprietary
    rights which may cover technology that may be required to practice
    this standard. Please address the information to the IETF Executive
    Director.

    The IETF has been notified of intellectual property rights claimed
    in regard to some or all of the specification contained in this
    document. For more information consult the online list of claimed
    rights.

 16 Full Copyright Statement

    Copyright (C) The Internet Society (2004). All Rights Reserved.

    This document and translations of it may be copied and furnished to
    others, and derivative works that comment on or otherwise explain it
    or assist in its implementation may be prepared, copied, published
    and distributed, in whole or in part, without restriction of any
    kind, provided that the above copyright notice and this paragraph
    are included on all such copies and derivative works. However, this
    document itself may not be modified in any way, such as by removing
    the copyright notice or references to the Internet Society or other
    Internet organizations, except as needed for the purpose of
    developing Internet standards in which case the procedures for
    copyrights defined in the Internet Standards process must be
    followed, or as required to translate it into languages other than
    English.

    The limited permissions granted above are perpetual and will not be
    revoked by the Internet Society or its successors or assignees.

    This document and the information contained herein is provided on an
    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
    TASK FORCE DISCLAIMS 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.