draft-ietf-rap-cops-tls-04.txt   draft-ietf-rap-cops-tls-05.txt 
Internet Draft Jesse Walker Internet Draft Jesse Walker
Expiration: December 2002 Amol Kulkarni Expiration: July 2003 Amol Kulkarni
File: draft-ietf-rap-cops-tls-04.txt Intel Corp. File: draft-ietf-rap-cops-tls-05.txt Intel Corp.
COPS Over TLS COPS Over TLS
Last Updated: June 30, 2002 Last Updated: February 6, 2003
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other
at any time. It is inappropriate to use Internet-Drafts as documents at any time. It is inappropriate to use Internet-Drafts
reference material or to cite them other than as "work in progress." as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 2, line 5 skipping to change at page 2, line 5
this document are to be interpreted as described in [RFC-2119]. this document are to be interpreted as described in [RFC-2119].
Abstract Abstract
This memo describes how to use TLS to secure COPS connections over This memo describes how to use TLS to secure COPS connections over
the Internet. the Internet.
Please send comments on this document to the rap@ops.ietf.org Please send comments on this document to the rap@ops.ietf.org
mailing list. mailing list.
Table Of Contents Table of Contents
1 Introduction....................................................3 1 Introduction...................................................3
2 COPS Over TLS...................................................3 2 COPS Over TLS..................................................3
3 Separate Ports versus Upward Negotiation.........................3 3 Separate Ports versus Upward Negotiation........................3
3.1 The COPS/TLS approach..........................................4 3.1 The COPS/TLS approach.........................................4
3.2.1 The ClientSI object format...................................4 3.2.1 The ClientSI object format..................................4
3.2.2 Error Codes and Sub-Codes....................................5 3.2.2 Error Codes and Sub-Codes...................................5
4 Usage Scenarios..................................................5 4 Usage Scenarios.................................................5
4.1 Security Required By Client and Server.........................5 4.1 Security Required By Client and Server........................5
4.2 Security Required By Client and Optional on Server.............5 4.2 Security Required By Client and Optional on Server............5
4.3 Security Optional on Client and Required on Server.............6 4.3 Security Optional on Client and Required on Server............6
4.4 Security Optional on Client and Server.........................6 4.4 Security Optional on Client and Server........................6
4.5 Security Supported by Client but not by Server.................6 4.5 Security Supported by Client but not by Server................6
4.6 Security supported by Server but not by Client.................6 4.6 Security supported by Server but not by Client................6
4.7 Security not Supported by either Client or Server..............6 4.7 Security not Supported by either Client or Server.............6
5 Secure Connection Initiation.....................................6 5 Secure Connection Initiation....................................6
6 Connection Closure...............................................7 6 Connection Closure..............................................7
6.1. PEP System Behavior..........................................7 6.1. PEP System Behavior.........................................7
6.2. PDP System Behavior..........................................7 6.2. PDP System Behavior.........................................7
7 Port Number......................................................8 7 Port Number.....................................................8
8 Endpoint Identification and Access Control......................8 8 Endpoint Identification and Access Control.....................8
8.1 PDP Identity..................................................8 8.1 PDP Identity.................................................8
8.2 PEP Identity..................................................9 8.2 PEP Identity.................................................9
9 Other Considerations............................................10 9 Other Considerations...........................................10
9.1 Backward Compatibility........................................10 9.1 Backward Compatibility.......................................10
9.2 IANA Considerations...........................................10 9.2 IANA Considerations..........................................10
10 Security Considerations.......................................10 10 Security Considerations......................................10
11 Acknowledgements..............................................10 11 Acknowledgements.............................................10
12 References....................................................10 12 References....................................................10
12 Author Addresses..............................................10 12.1 Normative References........................................10
12.2 Informative References......................................10
13 Authors' Addresses...........................................11
1 Introduction 1 Introduction
COPS [COPS] was designed to distribute clear-text policy information COPS [COPS] was designed to distribute clear-text policy information
from a centralized Policy Decision Point (PDP) to a set of Policy from a centralized Policy Decision Point (PDP) to a set of Policy
Enforcement Points (PEP) in the Internet. COPS provides its own Enforcement Points (PEP) in the Internet. COPS provides its own
security mechanisms to protect the per-hop integrity of the deployed security mechanisms to protect the per-hop integrity of the deployed
policy. However, the use of COPS for sensitive applications such as policy. However, the use of COPS for sensitive applications such as
some types of security policy distribution requires additional some types of security policy distribution requires additional
security measures, such as data privacy. This is because some security measures, such as data privacy. This is because some
organizations find it necessary to hide some or all of their security organizations find it necessary to hide some or all of their
policies, e.g., because policy distribution to devices such as mobile security policies, e.g., because policy distribution to devices such
platforms can cross domain boundaries. as mobile platforms can cross domain boundaries.
TLS [TLS] was designed to provide channel-oriented security. TLS TLS [TLS] was designed to provide channel-oriented security. TLS
standardizes SSL and may be used with any connection-oriented standardizes SSL and may be used with any connection-oriented
service. TLS provides mechanisms for both one- and two-way service. TLS provides mechanisms for both one- and two-way
authentication, dynamic session keying, and data stream privacy and authentication, dynamic session keying, and data stream privacy and
integrity. integrity.
This document describes how to use COPS over TLS. "COPS over TLS" is This document describes how to use COPS over TLS. "COPS over TLS" is
abbreviated COPS/TLS. abbreviated COPS/TLS.
2 COPS Over TLS 2 COPS Over TLS
COPS/TLS is very simple: use COPS over TLS similar to how you would 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 use COPS over TCP (COPS/TCP). Apart from a specific procedure used
initialize the connection, there is no difference between COPS/TLS to initialize the connection, there is no difference between
and COPS/TCP. COPS/TLS and COPS/TCP.
3 Separate Ports versus Upward Negotiation 3 Separate Ports versus Upward Negotiation
There are two ways in which insecure and secure versions of the same There are two ways in which insecure and secure versions of the same
protocol can be run simultaneously. protocol can be run simultaneously.
In the first method, the secure version of the protocol is also In the first method, the secure version of the protocol is also
allocated a well-known port. This strategy of having well-known port allocated a well-known port. This strategy of having well-known port
numbers for both, the secure and insecure versions, is known as numbers for both, the secure and insecure versions, is known as
'Separate Ports'. The clients requiring security can simply connect 'Separate Ports'. The clients requiring security can simply connect
to the well-known secure port. The main advantage of this strategy is to the well-known secure port. The main advantage of this strategy
that it is very simple to implement, with no modifications needed to is that it is very simple to implement, with no modifications needed
existing insecure implementations. Thus it is the most popular to existing insecure implementations. Thus it is the most popular
approach. The disadvantage, however, is that it doesn't scale well, approach. The disadvantage, however, is that it doesn't scale well,
with a new port required for each secure implementation. Hence, the with a new port required for each secure implementation. Hence, the
IESG discourages designers from using the strategy. IESG discourages designers from using the strategy.
The second method is known as 'Upward Negotiation'. In this method, The second method is known as 'Upward Negotiation'. In this method,
the secure and insecure versions of the protocol run on the same the secure and insecure versions of the protocol run on the same
port. The client connects to the server, both discover each others' port. The client connects to the server, both discover each others'
capabilities, and start security negotiations if desired. This method capabilities, and start security negotiations if desired. This
usually requires some changes in the protocol being secured so that method usually requires some changes in the protocol being secured
it can support the upward negotiation. There is also a high handshake so that it can support the upward negotiation. There is also a high
overhead involved in this method. handshake overhead involved in this method.
3.1 The COPS/TLS approach 3.1 The COPS/TLS approach
COPS/TLS uses a combination of both these approaches to achieve COPS/TLS uses a combination of both these approaches to achieve
simultaneous operation with COPS/TCP. Initially, the authors had simultaneous operation with COPS/TCP. Initially, the authors had
hoped to use the Separate Ports strategy for implementing COPS/TLS, hoped to use the Separate Ports strategy for implementing COPS/TLS,
however, due to the reluctance of the IESG to assign a well-known however, due to the reluctance of the IESG to assign a well-known
port, they settled on the following approach. port, they settled on the following approach.
When the COPS/TLS server is initialized, it SHOULD bind to any non- When the COPS/TLS server is initialized, it SHOULD bind to any non-
well-known port of its choice. The standard COPS server running over well-known port of its choice. The standard COPS server running over
TCP MUST know the TCP port on which COPS/TLS is running. How this is TCP MUST know the TCP port on which COPS/TLS is running. How this is
achieved is outside the scope of this document. achieved is outside the scope of this document.
The system acting as the PEP also acts as the TLS client. It needs to The system acting as the PEP also acts as the TLS client. It needs
first connect to the COPS/TCP server, from where it can be redirected to first connect to the COPS/TCP server, from where it can be
to the COPS/TLS server. redirected to the COPS/TLS server.
3.2 Object Format and Error Codes 3.2 Object Format and Error Codes
This section describes the ClientSI object sent in the ClientOpen This section describes the ClientSI object sent in the ClientOpen
message and the error codes the server returns. message and the error codes the server returns.
3.2.1 The ClientSI object format 3.2.1 The ClientSI object format
0 1 2 3 0 1 2 3
+----------+----------+----------+----------+ +----------+----------+----------+----------+
skipping to change at page 5, line 31 skipping to change at page 5, line 31
A new error sub-code has been added to the pre-existing error code A new error sub-code has been added to the pre-existing error code
12. The sub-code informs the client that it SHOULD use TLS when 12. The sub-code informs the client that it SHOULD use TLS when
connecting to the redirected server. In the future, more sub-codes connecting to the redirected server. In the future, more sub-codes
may be added to specify additional protocols. may be added to specify additional protocols.
Error Code 17 MAY be used by either Client or Server if they require Error Code 17 MAY be used by either Client or Server if they require
security but the other side doesn't support it. security but the other side doesn't support it.
4 Usage Scenarios 4 Usage Scenarios
When the client needs to open a secure connection with the server, it When the client needs to open a secure connection with the server,
SHOULD first connect to the non-secure port, and send a Client Open it SHOULD first connect to the non-secure port, and send a Client
message with a ClientType=0. Included in this message, MUST be a Open message with a ClientType=0. Included in this message, MUST be
ClientSI object, which lists the security capabilities of the client. a ClientSI object, which lists the security capabilities of the
client.
The following scenarios occur: The following scenarios occur:
4.1 Security Required By Client and Server 4.1 Security Required By Client and Server
If the server's internal policies allow the client to connect, the If the server's internal policies allow the client to connect, the
server MUST send a ClientClose message with a Redirect object, server MUST send a ClientClose message with a Redirect object,
redirecting the client to the COPS/TLS secure port. Additionally, the redirecting the client to the COPS/TLS secure port. Additionally,
error object included in the ClientClose message MUST have the error the error object included in the ClientClose message MUST have the
code = 12 and sub code = 1. error code = 12 and sub code = 1.
If the server's internal policies do not allow the client to connect, If the server's internal policies do not allow the client to
the server MUST send a ClientClose with an appropriate error code. connect, the server MUST send a ClientClose with an appropriate
error code.
4.2 Security Required By Client and Optional on Server 4.2 Security Required By Client and Optional on Server
If the server's internal policies allow the client to connect If the server's internal policies allow the client to connect
securely, the server MUST send a ClientClose message with a Redirect securely, the server MUST send a ClientClose message with a Redirect
object, redirecting the client to the COPS/TLS secure port. object, redirecting the client to the COPS/TLS secure port.
Additionally, the error object included in the ClientClose message Additionally, the error object included in the ClientClose message
MUST have the error code = 12 and sub code = 1. MUST have the error code = 12 and sub code = 1.
If the server's internal policies do not allow the client to connect If the server's internal policies do not allow the client to connect
securely, the server MUST send a ClientClose with error code 16 or securely, the server MUST send a ClientClose with error code 16 or
another more appropriate error code. another more appropriate error code.
4.3 Security Optional on Client and Required on Server 4.3 Security Optional on Client and Required on Server
Depending upon its internal policies, the server MAY send a Depending upon its internal policies, the server MAY send a
ClientClose message with a Redirect object, redirecting the client to ClientClose message with a Redirect object, redirecting the client
the COPS/TLS secure port. to the COPS/TLS secure port.
4.4 Security Optional on Client and Server 4.4 Security Optional on Client and Server
Depending upon its internal policies, the server MAY send a Depending upon its internal policies, the server MAY send a
ClientClose message with a Redirect object, redirecting the client to ClientClose message with a Redirect object, redirecting the client
the COPS/TLS secure port. to the COPS/TLS secure port.
Optionally, the server MAY proceed to establish an insecure Optionally, the server MAY proceed to establish an insecure
connection over COPS/TCP. connection over COPS/TCP.
4.5 Security Supported by Client but not by Server 4.5 Security Supported by Client but not by Server
If the Client's capabilities specify that security is optional, the If the Client's capabilities specify that security is optional, the
server MAY proceed to establish an insecure connection. Otherwise, it server MAY proceed to establish an insecure connection. Otherwise,
MUST send a ClientClose with the error code 16. it MUST send a ClientClose with the error code 16.
4.6 Security supported by Server but not by Client 4.6 Security supported by Server but not by Client
If security is required by the server it MUST send a ClientClose with If security is required by the server it MUST send a ClientClose
the error code 16. If security is optional on the server, it MAY with the error code 16. If security is optional on the server, it
establish an insecure connection with the client. MAY establish an insecure connection with the client.
4.7 Security not Supported by either Client or Server 4.7 Security not Supported by either Client or Server
This is the regular COPS/TCP case as described in [COPS]. In this This is the regular COPS/TCP case as described in [COPS]. In this
case, only an insecure connection is possible. case, only an insecure connection is possible.
5 Secure Connection Initiation 5 Secure Connection Initiation
Once the PEP receives a redirect from the COPS/TCP server, it 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 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 succeeds, the PEP system sends the TLS ClientHello to begin the TLS
handshake. When the TLS handshake completes, the PEP MAY initiate the handshake. When the TLS handshake completes, the PEP MAY initiate
first COPS message. All COPS data MUST be sent as TLS "application the first COPS message. All COPS data MUST be sent as TLS
data". Normal COPS behavior follows. "application data". Normal COPS behavior follows.
All PEP implementations of COPS/TLS MUST support an access control All PEP implementations of COPS/TLS MUST support an access control
mechanism to identify authorized PDPs. This requirement provides a mechanism to identify authorized PDPs. This requirement provides a
level of assurance that the policy arriving at the PEP is actually level of assurance that the policy arriving at the PEP is actually
valid. The access control mechanism implemented is outside the scope valid. The access control mechanism implemented is outside the scope
of this document. PEP implementations SHOULD require the use of this of this document. PEP implementations SHOULD require the use of this
access control mechanism for operation of COPS over TLS. When access access control mechanism for operation of COPS over TLS. When access
control is enabled, the PEP implementation MUST NOT initiate COPS/TLS control is enabled, the PEP implementation MUST NOT initiate
connections to systems not authorized as PDPs by the access control COPS/TLS connections to systems not authorized as PDPs by the access
mechanism. control mechanism.
Similarly, PDP COPS/TLS implementations MUST support an access Similarly, PDP COPS/TLS implementations MUST support an access
control mechanism permitting them to restrict their services to control mechanism permitting them to restrict their services to
authorized PEP systems only. However, implementations MUST NOT authorized PEP systems only. However, implementations MUST NOT
require the use of an access control mechanism at the PDP, as require the use of an access control mechanism at the PDP, as
organizations might not consider the types of policy being deployed organizations might not consider the types of policy being deployed
as sensitive, and therefore do not need to incur the expense of as sensitive, and therefore do not need to incur the expense of
managing credentials for the PEP systems. If access controls are managing credentials for the PEP systems. If access controls are
used, however, the PDP implementation MUST terminate COPS/TLS used, however, the PDP implementation MUST terminate COPS/TLS
connections from unauthorized PEP systems and log an error if an connections from unauthorized PEP systems and log an error if an
skipping to change at page 7, line 31 skipping to change at page 7, line 31
of a valid closure alert assures an implementation that no further of a valid closure alert assures an implementation that no further
data will arrive on that connection. The TLS specification requires data will arrive on that connection. The TLS specification requires
TLS implementations to initiate a closure alert exchange before TLS implementations to initiate a closure alert exchange before
closing a connection. It also permits TLS implementations to close closing a connection. It also permits TLS implementations to close
connections without waiting to receive closure alerts from the peer, connections without waiting to receive closure alerts from the peer,
provided they send their own first. A connection closed in this way provided they send their own first. A connection closed in this way
is known as an "incomplete close". TLS allows implementations to is known as an "incomplete close". TLS allows implementations to
reuse the session in this case, but COPS/TLS makes no use of this reuse the session in this case, but COPS/TLS makes no use of this
capability. capability.
A connection closed without first sending a closure alert is known as A connection closed without first sending a closure alert is known
a "premature close". Note that a premature close does not call into as a "premature close". Note that a premature close does not call
question the security of the data already received, but simply into question the security of the data already received, but simply
indicates that subsequent data might have been truncated. Because TLS indicates that subsequent data might have been truncated. Because
is oblivious to COPS message boundaries, it is necessary to examine TLS is oblivious to COPS message boundaries, it is necessary to
the COPS data itself (specifically the Message header) to determine examine the COPS data itself (specifically the Message header) to
whether truncation occurred. determine whether truncation occurred.
6.1. PEP System Behavior 6.1. PEP System Behavior
PEP implementations MUST treat premature closes as errors and any PEP implementations MUST treat premature closes as errors and any
data received as potentially truncated. The COPS protocol allows the data received as potentially truncated. The COPS protocol allows the
PEP system to find out whether truncation took place. A PEP system PEP system to find out whether truncation took place. A PEP system
detecting an incomplete close SHOULD recover gracefully. detecting an incomplete close SHOULD recover gracefully.
PEP systems MUST send a closure alert before closing the connection. PEP systems MUST send a closure alert before closing the connection.
Clients unprepared to receive any more data MAY choose not to wait Clients unprepared to receive any more data MAY choose not to wait
for the PDP system's closure alert and simply close the connection, for the PDP system's closure alert and simply close the connection,
thus generating an incomplete close on the PDP side. thus generating an incomplete close on the PDP side.
6.2. PDP System Behavior 6.2. PDP System Behavior
COPS permits a PEP to close the connection at any time, and requires COPS permits a PEP to close the connection at any time, and requires
PDPs to recover gracefully. In particular, PDPs SHOULD be prepared to PDPs to recover gracefully. In particular, PDPs SHOULD be prepared
receive an incomplete close from the PEP, since a PEP often shuts to receive an incomplete close from the PEP, since a PEP often shuts
down for operational reasons unrelated to the transfer of policy down for operational reasons unrelated to the transfer of policy
information between the PEP and PDP. information between the PEP and PDP.
Implementation note: The PDP ordinarily expects to be able to Implementation note: The PDP ordinarily expects to be able to
signal end of data by closing the connection. However, the PEP signal end of data by closing the connection. However, the PEP
may have already sent the closure alert and dropped the may have already sent the closure alert and dropped the
connection. connection.
PDP systems MUST attempt to initiate an exchange of closure alerts PDP systems MUST attempt to initiate an exchange of closure alerts
with the PEP system before closing the connection. PDP systems MAY with the PEP system before closing the connection. PDP systems MAY
close the connection after sending the closure alert, thus generating close the connection after sending the closure alert, thus
an incomplete close on the PEP side. generating an incomplete close on the PEP side.
7 Port Number 7 Port Number
The first data a PDP expects to receive from the PEP is a Client-Open The first data a PDP expects to receive from the PEP is a Client-
message. The first data a TLS server (and hence a COPS/TLS server) Open message. The first data a TLS server (and hence a COPS/TLS
expects to receive is the ClientHello. Consequently, COPS/TLS runs server) expects to receive is the ClientHello. Consequently,
over a separate port in order to distinguish it from COPS alone. When COPS/TLS runs over a separate port in order to distinguish it from
COPS/TLS runs over a TCP/IP connection, the TCP port is any non-well- COPS alone. When COPS/TLS runs over a TCP/IP connection, the TCP
known port of the PDP's choice. This port MUST be communicated to the port is any non-well-known port of the PDP's choice. This port MUST
COPS/TCP server running on the well-known COPS TCP port. The PEP may be communicated to the COPS/TCP server running on the well-known
use any TCP port. This does not preclude COPS/TLS from running over COPS TCP port. The PEP may use any TCP port. This does not preclude
another transport. TLS only presumes a reliable connection-oriented COPS/TLS from running over another transport. TLS only presumes a
data stream. reliable connection-oriented data stream.
8 Endpoint Identification and Access Control 8 Endpoint Identification and Access Control
Implementations of COPS/TLS MUST use X.509 v3 certificates conforming Implementations of COPS/TLS MUST use X.509 v3 certificates
to [PKIX] to identify PDP and PEP systems. COPS/TLS systems MUST conforming to [PKIX] to identify PDP and PEP systems. COPS/TLS
perform certificate verification processing conforming to [PKIX]. systems MUST perform certificate verification processing conforming
to [PKIX].
If a subjectAltName extension of type dNSName or iPAddress is present If a subjectAltName extension of type dNSName or iPAddress is
in the PDP's certificate, that MUST be used as the PDP identity. present in the PDP's certificate, that MUST be used as the PDP
Otherwise, the most specific Common Name field in the Subject field identity. Otherwise, the most specific Common Name field in the
of the certificate MUST be used. Subject field of the certificate MUST be used.
Matching is performed using the matching rules specified by [PKIX]. Matching is performed using the matching rules specified by [PKIX].
If more than one identity of a given type is present in the If more than one identity of a given type is present in the
certificate (e.g. more than one dNSName name, a match in any one of certificate (e.g. more than one dNSName name, a match in any one of
the set is considered acceptable.), the COPS system uses the first the set is considered acceptable.), the COPS system uses the first
name to match, except as noted below in the IP address checking name to match, except as noted below in the IP address checking
requirements. Names may contain the wildcard character * which is requirements. Names may contain the wildcard character * which is
considered to match any single domain name component or component considered to match any single domain name component or component
fragment. For example, *.a.com matches foo.a.com but not 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. bar.foo.a.com. f*.com matches foo.com but not foo.bar.com.
8.1 PDP Identity 8.1 PDP Identity
Generally, COPS/TLS requests are generated by the PEP consulting Generally, COPS/TLS requests are generated by the PEP consulting
bootstrap policy information identifying authorized PDPs. As a bootstrap policy information identifying authorized PDPs. As a
consequence, the hostname or IP address for the PDP is known to the consequence, the hostname or IP address for the PDP is known to the
PEP. How this bootstrap policy information arrives at the PEP is PEP. How this bootstrap policy information arrives at the PEP is
outside the scope of this document. However, all PEP implementations outside the scope of this document. However, all PEP implementations
MUST provide a mechanism to securely deliver or configure the MUST provide a mechanism to securely deliver or configure the
bootstrap policy. In particular, all PEP implementations MUST support bootstrap policy. In particular, all PEP implementations MUST
a mechanism to securely acquire the signing certificate of the support a mechanism to securely acquire the signing certificate of
authorized certificate authorities issuing PDP certificates, and MUST the authorized certificate authorities issuing PDP certificates, and
support a mechanism to securely acquire an access control list or MUST support a mechanism to securely acquire an access control list
filter identifying its set of authorized PDPs. or filter identifying its set of authorized PDPs.
PEP implementations that participate in multiple domains, such as PEP implementations that participate in multiple domains, such as
those on mobile platforms, MAY use different certificate authorities those on mobile platforms, MAY use different certificate authorities
and access control lists in each domain. and access control lists in each domain.
Organizations may choose to deliver some or all of the bootstrap Organizations may choose to deliver some or all of the bootstrap
policy configuration from an untrusted source, such as DHCP. In this policy configuration from an untrusted source, such as DHCP. In this
circumstance, COPS over TLS provides no protection from attack when circumstance, COPS over TLS provides no protection from attack when
this untrusted source is compromised. this untrusted source is compromised.
If the PDP hostname or IP address is available via the access control If the PDP hostname or IP address is available via the access
mechanism, the PEP MUST check it against the PDP's identity as control mechanism, the PEP MUST check it against the PDP's identity
presented in the PDP's TLS Certificate message. as presented in the PDP's TLS Certificate message.
In some cases the bootstrap policy will identify the authorized PDP In some cases the bootstrap policy will identify the authorized PDP
only by an IP address of the PDP system. In this case, the only by an IP address of the PDP system. In this case, the
subjectAltName MUST be present in the certificate, and it MUST subjectAltName MUST be present in the certificate, and it MUST
include an iPAdress format matching the expected name of the policy include an iPAdress format matching the expected name of the policy
server. server.
If the hostname of the PDP does not match the identity in the 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 certificate, a PEP on a user oriented system MUST either notify the
user (PEP systems MAY afford the user the opportunity to continue user (PEP systems MAY afford the user the opportunity to continue
with the connection in any case) or terminate the connection with a with the connection in any case) or terminate the connection with a
bad certificate error. PEPs on unattended systems MUST log the error bad certificate error. PEPs on unattended systems MUST log the error
to an appropriate audit log (if available) and MUST terminate the to an appropriate audit log (if available) and MUST terminate the
connection (with a bad certificate error). Unattended PEP systems MAY connection (with a bad certificate error). Unattended PEP systems
provide a configuration setting that disables this check, but then MAY provide a configuration setting that disables this check, but
MUST provide a setting which enables it. then MUST provide a setting which enables it.
8.2 PEP Identity 8.2 PEP Identity
When PEP systems are not access controlled, the PDP need have no 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 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 checks are neither possible nor necessary. In this case, there is no
requirement for PEP systems to register with a certificate authority, requirement for PEP systems to register with a certificate
and COPS over TLS uses one-way authentication, of the PDP to the PEP. authority, and COPS over TLS uses one-way authentication, of the PDP
to the PEP.
When PEP systems are access controlled, PEPs must be PKI clients in When PEP systems are access controlled, PEPs must be PKI clients in
the sense of [PKIX]. In this case, COPS over TLS uses two-way the sense of [PKIX]. In this case, COPS over TLS uses two-way
authentication, and the PDP MUST perform the same identity checks for authentication, and the PDP MUST perform the same identity checks
the PEPs as described above for the PDP. for the PEPs as described above for the PDP.
When access controls are in effect at the PDP, PDP implementations When access controls are in effect at the PDP, PDP implementations
MUST have a mechanism to securely acquire the signing certificates of MUST have a mechanism to securely acquire the signing certificates
the certificate authorities issuing certificates to any of the PEPs of the certificate authorities issuing certificates to any of the
they support. PEPs they support.
9 Other Considerations 9 Other Considerations
9.1 Backward Compatibility 9.1 Backward Compatibility
The client and server SHOULD be backward compatible with peers that The client and server SHOULD be backward compatible with peers that
do not support security. A client SHOULD be able to handle errors do not support security. A client SHOULD be able to handle errors
generated by a server which does not understand the ClientSI object generated by a server which does not understand the ClientSI object
mentioned above. Similarly, if a server receives a ClientOpen for mentioned above. Similarly, if a server receives a ClientOpen for
Client type=0, which does not contain the ClientSI object, it SHOULD Client type=0, which does not contain the ClientSI object, it SHOULD
assume that the client wishes to open a non-secure connection and assume that the client wishes to open a non-secure connection and
skipping to change at page 10, line 35 skipping to change at page 10, line 38
This entire document concerns security. This entire document concerns security.
11 Acknowledgements 11 Acknowledgements
This document freely plagiarizes and adapts Eric Rescorla's similar This document freely plagiarizes and adapts Eric Rescorla's similar
document RFC2818 that specifies how HTTP runs over TLS. Discussions document RFC2818 that specifies how HTTP runs over TLS. Discussions
with David Durham, Scott Hahn and Ylian Sainte-Hillaire also lead to with David Durham, Scott Hahn and Ylian Sainte-Hillaire also lead to
improvements in this document. improvements in this document.
12 References 12 References
12.1 Normative References
[COPS] Durham, D., Boyle, J., Cohen, R., Herzog, R., Rajan, R.,
Sastry, A., "The COPS (Common Open Policy Service) Protocol", RFC
2748, January 200.
[PKIX] Housley, R., Ford, W., Polk, W., Solo, D., "Internet Public
Key Infrastructure: Part I: X.509 Certificate and CRL Profile",
RFC 2459, January 1999.
[RFC2026] Bradner, S., "The Internet Standards Process - Revision [RFC2026] Bradner, S., "The Internet Standards Process - Revision
3", RFC 2026, October 1996 3", RFC 2026, October 1996
[RFC2119] Bradner, S., "Key Words for use in RFCs to indicate [RFC2119] Bradner, S., "Key Words for use in RFCs to indicate
Requirement Levels", RFC 2119, March 1997. Requirement Levels", RFC 2119, March 1997.
[COPS] Durham, D., Boyle, J., Cohen, R., Herzog, R., Rajan, R.,
Sastry, A., "The COPS (Common Open Policy Service) Protocol", RFC
2748, January 200.
[PKIX] Housley, R., Ford, W., Polk, W., Solo, D., "Internet
Public Key Infrastructure: Part I: X.509 Certificate and CRL
Profile", RFC 2459, January 1999.
[TLS] Dierks, T., Allen, C., "The TLS Protocol", RFC2246, January [TLS] Dierks, T., Allen, C., "The TLS Protocol", RFC2246, January
1999. 1999.
12.2 Informative References
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC2818, May 2000.
12 Author Addresses 13 Authors' Addresses
Jesse R. Walker Jesse R. Walker
Intel Corporation Intel Corporation
2111 N.E. 25th Avenue 2111 N.E. 25th Avenue
Hillsboro, OR 97214 Hillsboro, OR 97214
USA USA
jesse.walker@intel.com jesse.walker@intel.com
Amol Kulkarni Amol Kulkarni
Intel Corporation Intel Corporation
JF3-206 JF3-206
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/