draft-ietf-rap-cops-tls-11.txt   rfc4261.txt 
Internet Draft Jesse Walker Network Working Group J. Walker
Expiration: August 2005 Amol Kulkarni, Ed. Request for Comments: 4261 A. Kulkarni, Ed.
File: draft-ietf-rap-cops-tls-11.txt Intel Corp. Updates: 2748 Intel Corp.
Category: Standards Track December 2005
COPS Over TLS Common Open Policy Service (COPS)
Over Transport Layer Security (TLS)
Last Updated: February 5, 2004 Status of This Memo
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.
This document is an Internet-Draft and is subject to all provisions Copyright Notice
of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Copyright (C) The Internet Society (2005).
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 Abstract
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 This document describes how to use Transport Layer Security (TLS) to
http://www.ietf.org/ietf/1id-abstracts.txt secure Common Open Policy Service (COPS) connections over the
Internet.
The list of Internet-Draft Shadow Directories can be accessed at This document also updates RFC 2748 by modifying the contents of the
http://www.ietf.org/shadow.html. Client-Accept message.
Conventions used in this document Table Of Contents
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 1. Introduction ....................................................2
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 2. COPS Over TLS ...................................................3
this document are to be interpreted as described in RFC 2119 3. Separate Ports versus Upward Negotiation ........................3
[RFC2119]. 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
Abstract 1. Introduction
This document describes how to use Transport Layer Security (TLS) COPS [RFC2748] was designed to distribute clear-text policy
to secure Common Open Policy Service (COPS) connections over the information from a centralized Policy Decision Point (PDP) to a set
Internet. 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.
This document also updates RFC 2748 by modifying the contents of TLS [RFC2246] was designed to provide channel-oriented security. TLS
the Client-Accept message. 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.
Table Of Contents This document describes how to use COPS over TLS. "COPS over TLS" is
abbreviated COPS/TLS.
Glossary..........................................................3 Glossary
1 Introduction...................................................3
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...........................................7
7 Endpoint Identification and Access Control.....................8
7.1 PDP Identity..................................................8
7.2 PEP Identity..................................................9
8 Backward Compatibility.........................................9
9 IANA Considerations............................................10
10 Security Considerations.......................................10
11 References....................................................10
11.1 Normative References........................................10
11.2 Informative References......................................11
12 Author Addresses.............................................11
13 IPR Disclosure Acknowledgement...............................11
14 Disclaimer of Validity.......................................11
15 Copyright Statement..........................................12
16 Disclaimer...................................................12
17 Acknowledgements.............................................12
Glossary COPS - Common Open Policy Service. See [RFC2748].
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/TCP - A plain-vanilla implementation of COPS.
COPS [RFC2748] was designed to distribute clear-text policy COPS/TLS - A secure implementation of COPS using TLS.
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 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 PDP - Policy Decision Point. Also referred to as the Policy Server.
standardizes SSL and may be used with any connection-oriented See [RFC2753].
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 PEP - Policy Enforcement Point. Also referred to as the Policy
abbreviated COPS/TLS. Client. See [RFC2753].
2 COPS Over TLS Conventions used in this document
COPS/TLS is very simple: use COPS over TLS similar to how you would The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
use COPS over TCP (COPS/TCP). Apart from a specific procedure used "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
to initialize the connection, there is no difference between document are to be interpreted as described in RFC 2119 [RFC2119].
COPS/TLS and COPS/TCP.
3 Separate Ports versus Upward Negotiation 2. COPS Over TLS
There are two ways in which insecure and secure versions of the same COPS/TLS is very simple: use COPS over TLS similar to how you would
protocol can be run simultaneously. 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.
In the first method, the secure version of the protocol is also 3. Separate Ports versus Upward Negotiation
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, with a new
port 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, There are two ways in which insecure and secure versions of the same
the secure and insecure versions of the protocol run on the same protocol can be run simultaneously.
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.
In view of the many issues with the Separate Ports approach, the In the first method, the secure version of the protocol is also
authors have decided to use the Upward Negotiation method for allocated a well-known port. This strategy of having well-known port
COPS/TLS. 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].
4 COPS/TLS Objects and Error codes 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.
This section describes the COPS objects and error codes needed to In view of the many issues with the Separate Ports approach, the
support COPS/TLS. authors have decided to use the Upward Negotiation method for
COPS/TLS.
4.1 The TLS Message Integrity Object (Integrity-TLS) 4. COPS/TLS Objects and Error codes
The TLS Integrity object is used by the PDP and the PEP to start the This section describes the COPS objects and error codes needed to
TLS negotiation. This object should be included only in the Client- support COPS/TLS.
Open or Client-Accept messages. It MUST NOT be included in any other
COPS message.
0 1 2 3 4.1. The TLS Message Integrity Object (Integrity-TLS)
+----------+----------+----------+----------+ The TLS Integrity object is used by the PDP and the PEP to start the
| Length (Octets) | C-Num=16 | C-Type=2 | TLS negotiation. This object should be included only in the Client-
+----------+----------+----------+----------+ Open or Client-Accept messages. It MUST NOT be included in any other
| //////// | Flags | COPS message.
+----------+----------+----------+----------+
Note: //// implies the field is reserved, set to 0 and should be 0 1 2 3
ignored on receipt.
Flags: 16 bits +----------+----------+----------+----------+
0x01 = StartTLS | Length (Octets) | C-Num=16 | C-Type=2 |
This flag indicates that the sender of the message +----------+----------+----------+----------+
wishes to initiate a TLS handshake. | //////// | Flags |
+----------+----------+----------+----------+
The Client-Type of any message containing this object MUST be 0. Note: //// implies the field is reserved, set to 0, and should
Client-Type 0 is used to negotiate COPS connection level security be ignored on receipt.
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 Flags: 16 bits
0x01 = StartTLS
This flag indicates that the sender of the message
wishes to initiate a TLS handshake.
This section uses the error codes described in section 2.2.8 (Error The Client-Type of any message containing this object MUST be 0.
Object) of [RFC2748]. 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.
Error Code: 13= Unknown COPS Object: 4.2. Error Codes
Sub-code (octet 2) contains the unknown object's C-Num and (octet 3) This section uses the error codes described in section 2.2.8 (Error
contains unknown object's C-Type. If the PEP or PDP does not support Object) of [RFC2748].
TLS, the C-Num specified will be 16 and the C-Type will be 2. This
demonstrates that the TLS version of the Integrity object not known.
This error code should be used by either PEP or PDP to indicate a Error Code: 13= Unknown COPS Object:
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 Sub-code (octet 2) contains the unknown object's C-Num, and (octet 3)
requested by the PEP in the Client-Open, it should send the contains unknown object's C-Type. If the PEP or PDP does not support
following error code: 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.
Error Code: 15= Authentication Required 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.
Where the Sub-code (octet 2) contains the C-Num=16 value for the If the PDP wishes to negotiate a different security mechanism than
Integrity Object and (octet 3) will specify the PDP requested by the PEP in the Client-Open, it MUST send the following
required/preferred Integrity object C-Type. If the server does not error code:
support any form of COPS-Security, it will 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 Error Code: 15= Authentication Required
Security negotiation may be initiated either by the PDP or the PEP. Where the Sub-code (octet 2) contains the C-Num=16 value for the
The PEP can initiate a negotiation via a Client-Open message, while Integrity Object and (octet 3) MUST specify the PDP
a PDP can initiate a negotiation via a Client-Accept message. 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.
Once the TLS connection is established, all COPS data MUST be sent 5. COPS/TLS Secure Connection Initiation
as TLS "application data".
5.1 PEP Initiated Security Negotiation 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.
A PEP MAY initiate a TLS security negotiation with a PDP using the Once the TLS connection is established, all COPS data MUST be sent as
Client-Open message. To do this, the Client-Open message MUST have a TLS "application data".
Client-Type of 0 and MUST include the Integrity-TLS object.
Upon receiving the Client-Open message, the PDP SHOULD respond with 5.1. PEP Initiated Security Negotiation
a Client-Accept message containing the Integrity-TLS object.
Note that in order to carry the Integrity-TLS object, the contents A PEP MAY initiate a TLS security negotiation with a PDP using the
of the Client-Accept message defined in section 3.7 of [RFC2748] Client-Open message. To do this, the Client-Open message MUST have a
need not change, other than the C-Type of the integrity object Client-Type of 0 and MUST include the Integrity-TLS object.
contained there-in should now be C-Type=2. For Example:
<Client-Accept> ::= <Common Header> Upon receiving the Client-Open message, the PDP SHOULD respond with a
<KA Timer> Client-Accept message containing the Integrity-TLS object.
[<ACCT Timer>]
[<Integrity (C-Num=16, C-Type=2)>]
Note also that this new format of the Client-Accept message does Note that in order to carry the Integrity-TLS object, the contents of
not replace or obsolete the existing Client-Accept message format, the Client-Accept message defined in section 3.7 of [RFC2748] need
which can continue to be used for non-secure COPS session not change, except that the C-Type of the integrity object contained
negotiations. there-in should now be C-Type=2. For Example:
Upon receiving the appropriate Client-Accept message, the PEP SHOULD <Client-Accept> ::= <Common Header>
initiate the TLS handshake. <KA Timer>
[<ACCT Timer>]
[<Integrity (C-Num=16, C-Type=2)>]
The message exchange is as follows: Note also that this new format of the Client-Accept message does not
C: Client-Open (Client-Type = 0, Integrity-TLS) replace or obsolete the existing Client-Accept message format, which
S: Client-Accept (Client-Type = 0, Integrity-TLS) can continue to be used for non-secure COPS session negotiations.
<TLS handshake>
C/S: <...further messages...>
In case the PDP does not wish to open a secure connection with the Upon receiving the appropriate Client-Accept message, the PEP SHOULD
PEP, it MUST reply with a Client-Close message and close the initiate the TLS handshake.
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 The message exchange is as follows:
MUST close the connection if the Integrity-TLS object is missing. It
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, in the ensuing Client-Close message.
5.2 PDP Initiated Security Negotiation C: Client-Open (Client-Type = 0, Integrity-TLS)
S: Client-Accept (Client-Type = 0, Integrity-TLS)
<TLS handshake>
C/S: <...further messages...>
The PEP initially opens a TCP connection with the PDP on the In case the PDP does not wish to open a secure connection with the
standard COPS port and sends a Client-Open message. This Client-Open PEP, it MUST reply with a Client-Close message and close the
message MUST have a Client-Type of 0. 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.
The PDP SHOULD then reply with a Client-Accept message. In order to A PEP requiring the Integrity-TLS object in a Client-Accept message
signal the PEP to start the TLS handshake, the PDP MUST include the MUST close the connection if the Integrity-TLS object is missing.
Integrity-TLS object in the Client-Accept message. 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.
Upon receiving the Client-Accept message with the Integrity-TLS 5.2. PDP Initiated Security Negotiation
object, the PEP SHOULD initiate the TLS handshake. If for any reason
the PEP cannot initiate the handshake, it MUST close the connection.
The message exchange is as follows: The PEP initially opens a TCP connection with the PDP on the standard
C: Client-Open (Client-Type = 0) COPS port and sends a Client-Open message. This Client-Open message
S: Client-Accept (Client-Type = 0, Integrity-TLS) MUST have a Client-Type of 0.
<TLS handshake>
C/S: <...further messages...>
After receiving the Client-Accept, the PEP MUST NOT send any The PDP SHOULD then reply with a Client-Accept message. In order to
messages until the TLS handshake is complete. Upon receiving any signal the PEP to start the TLS handshake, the PDP MUST include the
message from the PEP before the TLS handshake starts, the PDP MUST Integrity-TLS object in the Client-Accept message.
issue a Client-Close message with an error code 15= Authentication
Required.
A PDP wishing to negotiate security with a PEP having an existing Upon receiving the Client-Accept message with the Integrity-TLS
non-secure connection MUST send a Client-Close with the error code object, the PEP SHOULD initiate the TLS handshake. If for any reason
15= Authentication required, with the Sub-code (octet 2) containing the PEP cannot initiate the handshake, it MUST close the connection.
the required Integrity object's C-Num=16 and (octet 3) containing
the required Integrity object's C-Type=2 and 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 The message exchange is as follows:
TLS provides facilities to securely close its connections. Reception C: Client-Open (Client-Type = 0)
of a valid closure alert assures an implementation that no further S: Client-Accept (Client-Type = 0, Integrity-TLS)
data will arrive on that connection. The TLS specification requires <TLS handshake>
TLS implementations to initiate a closure alert exchange before C/S: <...further messages...>
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 After receiving the Client-Accept, the PEP MUST NOT send any messages
as a "premature close". Note that a premature close does not call until the TLS handshake is complete. Upon receiving any message from
into question the security of the data already received, but simply the PEP before the TLS handshake starts, the PDP MUST issue a
indicates that subsequent data might have been truncated. Because Client-Close message with an error code 15= Authentication Required.
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 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.
PEP implementations MUST treat premature closes as errors and any 6. Connection Closure
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 SHOULD send a closure alert before closing the TLS provides facilities to securely close its connections. Reception
connection. PEPs unprepared to receive any more data MAY choose not of a valid closure alert assures an implementation that no further
to wait for the PDP system's closure alert and simply close the data will arrive on that connection. The TLS specification requires
connection, thus generating an incomplete close on the PDP side. 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.
6.2 PDP System Behavior 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.
COPS permits a PEP to close the connection at any time, and requires 6.1. PEP System Behavior
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 PEP implementations MUST treat premature closes as errors and any
signal end of data by closing the connection. However, the PEP data received as potentially truncated. The COPS protocol allows the
may have already sent the closure alert and dropped the PEP system to find out whether truncation took place. A PEP system
connection. detecting an incomplete close SHOULD recover gracefully.
PDP systems MUST attempt to initiate an exchange of closure alerts PEP systems SHOULD send a closure alert before closing the
with the PEP system before closing the connection. PDP systems MAY connection. PEPs unprepared to receive any more data MAY choose not
close the connection after sending the closure alert, thus to wait for the PDP system's closure alert and simply close the
generating an incomplete close on the PEP side. connection, thus generating an incomplete close on the PDP side.
7 Endpoint Identification and Access Control 6.2. PDP System Behavior
All PEP implementations of COPS/TLS MUST support an access control COPS permits a PEP to close the connection at any time, and requires
mechanism to identify authorized PDPs. This requirement provides a PDPs to recover gracefully. In particular, PDPs SHOULD be prepared
level of assurance that the policy arriving at the PEP is actually to receive an incomplete close from the PEP, since a PEP often shuts
valid. PEP deployments SHOULD require the use of this access control down for operational reasons unrelated to the transfer of policy
mechanism for operation of COPS over TLS. When access control is information between the PEP and PDP.
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 Implementation note: The PDP ordinarily expects to be able to
control mechanism permitting them to restrict their services to signal the end of data by closing the connection. However, the
authorized PEP systems only. However, deployments MAY choose not to PEP may have already sent the closure alert and dropped the
use an access control mechanism at the PDP, as organizations might connection.
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 PDP systems MUST attempt to initiate an exchange of closure alerts
conforming to [RFC3280] to identify PDP and PEP systems. COPS/TLS with the PEP system before closing the connection. PDP systems MAY
systems MUST perform certificate verification processing conforming close the connection after sending the closure alert, thus generating
to [RFC3280]. an incomplete close on the PEP side.
If a subjectAltName extension of type dNSName or iPAddress is 7. Endpoint Identification and Access Control
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 of the types 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 All PEP implementations of COPS/TLS MUST support an access control
[RFC3280]. If more than one identity of a given type is present in mechanism to identify authorized PDPs. This requirement provides a
the certificate (e.g. more than one dNSName name in the level of assurance that the policy arriving at the PEP is actually
subjectAltName certificate extension), a match in any one of the valid. PEP deployments SHOULD require the use of this access control
provided identities is acceptable. Generally, the COPS system uses mechanism for operation of COPS over TLS. When access control is
the first name for matching, except as noted below in the IP enabled, the PEP implementation MUST NOT initiate COPS/TLS
address checking requirements. connections to systems not authorized as PDPs by the access control
mechanism.
7.1 PDP Identity 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.
Generally, COPS/TLS requests are generated by the PEP consulting Implementations of COPS/TLS MUST use X.509 v3 certificates conforming
bootstrap policy information that identifies PDPs that the PEP is to [RFC3280] to identify PDP and PEP systems. COPS/TLS systems MUST
authorized to connect to. This policy provides the PEP with the perform certificate verification processing conforming to [RFC3280].
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 If a subjectAltName extension of type dNSName or iPAddress is present
anchor for each authorized Certification Authority (CA) that issues in the PDP's certificate, it MUST be used as the PDP identity. If
PDP certificates. Also, the PEPs MUST support a mechanism to both types are present, dNSName SHOULD be used as the PDP identity.
securely acquire an access control list or filter identifying the If neither type is present, the most specific Common Name field in
set of authorized PDPs associated with each CA. the Subject field of the certificate SHOULD be used.
PEP deployments that participate in multiple domains, such as those Matching is performed using the matching rules specified by
on mobile platforms, MAY use different CAs and access control lists [RFC3280]. If more than one identity of a given type is present in
in each domain. 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.
If the PDP hostname or IP address is available via the bootstrap 7.1. PEP Identity
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 When PEP systems are not access controlled, the PDP does not need
only by an IP address of the PDP system. In this case, the external knowledge of what the PEP's identity ought to be and so
subjectAltName MUST be present in the certificate, and it MUST checks are neither possible nor necessary. In this case, there is no
include an iPAdress format matching the expected name of the policy requirement for PEP systems to register with a certificate authority,
server. and COPS over TLS uses one-way authentication, of the PDP to the PEP.
If the hostname of the PDP does not match the identity in the When PEP systems are access controlled, PEPs MUST be the subjects of
certificate, a PEP on a user oriented system MUST either notify the end entity certificates [RFC3280]. In this case, COPS over TLS uses
user (PEP systems MAY afford the user the opportunity to continue two-way authentication, and the PDP MUST perform the same identity
with the connection in any case) or terminate the connection with a checks for the PEPs as described above for the PDP.
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.
7.2 PEP Identity 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.
When PEP systems are not access controlled, the PDP need have no 7.2. PDP Identity
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 Generally, COPS/TLS requests are generated by the PEP consulting
of end entity certificates [RFC3280]. In this case, COPS over TLS bootstrap policy information that identifies PDPs that the PEP is
uses two-way authentication, and the PDP MUST perform the same authorized to connect to. This policy provides the PEP with the
identity checks for the PEPs as described above for the PDP. 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.
When access controls are in effect at the PDP, PDP implementations All PEP implementations MUST be able to securely acquire the trust
MUST have a mechanism to securely acquire the trust anchor for each anchor for each authorized Certification Authority (CA) that issues
authorized Certification Authority (CA) that issues certificates to PDP certificates. Also, the PEPs MUST support a mechanism to
supported PEPs. 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
and ACLs. At a minimum, trust anchors and ACLs may be installed
manually.
8 Backward Compatibility PEP deployments that participate in multiple domains, such as those
The PEP and PDP SHOULD be backward compatible with peers that have on mobile platforms, MAY use different CAs and access control lists
not been modified to support COPS/TLS. They SHOULD handle errors in each domain.
generated in response to the Integrity-TLS object.
9 IANA Considerations 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.
The IANA shall add the following C-Num, C-Type combination for the In some cases, the bootstrap policy will identify the authorized PDP
Integrity-TLS object to the registry at only by an IP address of the PDP system. In this case, the
http://www.iana.org/assignments/cops-parameters: subjectAltName MUST be present in the certificate, and it MUST
0x10 0x02 Message Integrity, Integrity-TLS [RFCxxxx] include an iPAddress format matching the expected name of the policy
server.
For Client-Type 0, the IANA shall add the following Flags value for If the hostname of the PDP does not match the identity in the
the Integrity-TLS object: certificate, a PEP on a user-oriented system MUST either notify the
0x01 = StartTLS 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.
Further, for Client-Type 0, the IANA shall add the following text 8. Cipher Suite Requirements
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 Implementations MUST support the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher
Octet 2 Octet 3 suite. All other cipher suites are optional.
---------------------------------------------------
15 16 0 No security
15 16 2 Integrity-TLS supported/preferred
Further values for the Flags field and the reserved field can only 9. Backward Compatibility
be assigned by IETF Consensus rule as defined in [RFC2434].
10 Security Considerations 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.
A COPS PDP and PEP MUST check the results of the TLS negotiation to 10. IANA Considerations
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 The IANA has added the following C-Num, C-Type combination for the
Integrity-TLS object or altering the Client-Open or Client-Accept Integrity-TLS object to the registry at
messages. If security is required, the PEP and PDP bootstrap policy http://www.iana.org/assignments/cops-parameters:
must specify this, and PEP and PDP implementations should reject
Client-Open or Client-Accept messages that fail to include an
Integrity-TLS object.
11 References 0x10 0x02 Message Integrity, Integrity-TLS [RFC4261]
11.1 Normative References For Client-Type 0, the IANA has added the following Flags value for
the Integrity-TLS object:
[RFC2119] Bradner, S., "Key Words for use in RFCs to indicate 0x01 = StartTLS
Requirement Levels", RFC 2119, March 1997.
[RFC2748] Durham, D., Boyle, J., Cohen, R., Herzog, R., Rajan, Further, for Client-Type 0, the IANA has added the following text for
R., Sastry, A., "The COPS (Common Open Policy Service) Protocol", Error Sub-Codes:
RFC 2748, January 2000.
[RFC2753] Yavatkar, R., Pendarakis, D., Guerin, R., "A Framework Error Code: 15
for Policy-based Admission Control", RFC 2753, January 2000. Error Sub-Code:
Octet 2: C-Num of the Integrity object
Octet 3: C-Type of the supported/preferred Integrity object or
Zero.
[RFC3280] Housley, R., Ford, W., Polk, W., Solo, D., "Internet Error-Code Error-SubCode Description
X.509 Public Key Infrastructure Certificate and Certificate Octet 2 Octet 3
Revocation List (CRL) Profile ", RFC 3280, April 2002. ---------------------------------------------------
15 16 0 No security
15 16 2 Integrity-TLS supported/preferred
[RFC2246] Dierks, T., Allen, C., "The TLS Protocol", RFC 2246, Further values for the Flags field and the reserved field can only be
January 1999. assigned by IETF Consensus rule, as defined in [RFC2434].
11.2 Informative References 11. Security Considerations
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 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.
[RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC A man-in-the-middle attack can be launched by deleting the
2595, June 1999. 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.
[RFC2434] Alvestrand, H., Narten, T., "Guidelines for writing an 12. Acknowledgements
IANA Considerations Section in RFCs", BCP 26, RFC 2434, October
1998.
12 Author Addresses This document freely plagiarizes and adapts Eric Rescorla's similar
document [RFC2818] that specifies how HTTP runs over TLS.
Amol Kulkarni Discussions with David Durham, Scott Hahn, and Ylian Sainte-Hillaire
Intel Corporation also lead to improvements in this document.
2111 N.E. 25th Avenue
Hillsboro, OR 97214
USA
amol[dot]kulkarni[at]intel[dot]com
Jesse R. Walker The authors wish to thank Uri Blumenthal for doing a thorough
Intel Corporation security review of the document.
2111 N.E. 25th Avenue
Hillsboro, OR 97214
USA
jesse[dot]walker[at]intel[dot]com
13 IPR Disclosure Acknowledgement 13. References
By submitting this Internet-Draft, we certify that any applicable 13.1. Normative References
patent or other IPR claims of which we are aware have been
disclosed, and any of which we become aware will be disclosed, in
accordance with RFC 3668.
14 Disclaimer of Validity [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
The IETF takes no position regarding the validity or scope of any [RFC2748] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R.,
Intellectual Property Rights or other rights that might be claimed and A. Sastry, "The COPS (Common Open Policy Service)
to pertain to the implementation or use of the technology described Protocol", RFC 2748, January 2000.
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 [RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework
assurances of licenses to be made available, or the result of an for Policy-based Admission Control", RFC 2753, January
attempt made to obtain a general license or permission for the use 2000.
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 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
copyrights, patents or patent applications, or other proprietary X.509 Public Key Infrastructure Certificate and Certificate
rights that may cover technology that may be required to implement Revocation List (CRL) Profile", RFC 3280, April 2002.
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
15 Copyright Statement [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
Copyright (C) The Internet Society (2004). This document is subject 13.2. Informative References
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
16 Disclaimer [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
This document and the information contained herein are provided on [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595,
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE June 1999.
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.
17 Acknowledgements [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
This document freely plagiarizes and adapts Eric Rescorla's similar Authors' Addresses
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.
Funding for the RFC Editor function is currently provided by the Amol Kulkarni
Internet Society. 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
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.
 End of changes. 128 change blocks. 
473 lines changed or deleted 410 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/