draft-ietf-rap-cops-tls-07.txt   draft-ietf-rap-cops-tls-08.txt 
Internet Draft Jesse Walker Internet Draft Jesse Walker
Expiration: May 2004 Amol Kulkarni, Ed. Expiration: February 2005 Amol Kulkarni, Ed.
File: draft-ietf-rap-cops-tls-07.txt Intel Corp. File: draft-ietf-rap-cops-tls-08.txt Intel Corp.
COPS Over TLS COPS Over TLS
Last Updated: November 24, 2003 Last Updated: August 16, 2004
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.
skipping to change at page 2, line 9 skipping to change at page 2, line 9
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
Glossary..........................................................3 Glossary..........................................................3
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 4 COPS/TLS Objects and Error codes...............................4
3.2.1 The ClientSI object format..................................5 4.1 The StartTLS ClientSI Object..................................4
3.2.2 Error Codes and Sub-Codes...................................5 4.2 Error Codes...................................................4
4 Usage Scenarios.................................................6 5 COPS/TLS Secure Connection Initiation..........................4
4.1 Security Mandatory on both, Client and Server.................6 5.1 PDP Initiated Security Negotiation............................4
4.2 Security Mandatory on Client and Optional on Server...........7 5.2 PEP Initiated Security Negotiation............................5
4.3 Security Optional on Client and Mandatory on Server...........7 6 Connection Closure.............................................6
4.4 Security Optional on both, Client and Server..................7 6.1 PEP System Behavior...........................................6
4.5 Security Mandatory on Client but not supported by Server......7 6.2 PDP System Behavior...........................................6
4.6 Security Optional on Client but not supported by Server.......7 7 Port Number....................................................7
4.7 Security Mandatory on Server but not supported by Client......7 8 Endpoint Identification and Access Control.....................7
4.8 Security Optional on Server but not supported by Client.......7 8.1 PDP Identity..................................................8
5 Secure Connection Initiation....................................7 8.2 PEP Identity..................................................8
6 Connection Closure..............................................8 9 Backward Compatibility.........................................9
6.1. PEP System Behavior.........................................8 10 IANA Considerations............................................9
6.2. PDP System Behavior.........................................9 11 Security Considerations........................................9
7 Port Number.....................................................9 12 Acknowledgements...............................................9
8 Endpoint Identification and Access Control.....................9 13 References....................................................10
8.1 PDP Identity................................................10 13.1 Normative References........................................10
8.2 PEP Identity................................................11 13.2 Informative References......................................10
9 Other Considerations...........................................11 14 Author Addresses.............................................10
9.1 Backward Compatibility.......................................11 15 Intellectual Property Statement..............................11
9.2 IANA Considerations..........................................11 16 Full Copyright Statement......................................11
10 Security Considerations......................................11
11 Acknowledgements.............................................11
12 References....................................................12
12.1 Normative References........................................12
12.2 Informative References......................................12
13 Author Addresses.............................................12
Glossary Glossary
COPS - Common Open Policy Service. See [RFC2748]. COPS - Common Open Policy Service. See [RFC2748].
COPS/TCP - A plain-vanilla implementation of COPS. COPS/TCP - A plain-vanilla implementation of COPS.
COPS/TLS - A secure implementation of COPS using TLS. COPS/TLS - A secure implementation of COPS using TLS.
PDP - Policy Decision Point. Also referred to as the Policy PDP - Policy Decision Point. Also referred to as the Policy
Server. See [RFC2753]. Server. See [RFC2753].
PEP - Policy Enforcement Point. Also referred to as the Policy PEP - Policy Enforcement Point. Also referred to as the Policy
Client. See [RFC2753]. Client. See [RFC2753].
1 Introduction 1 Introduction
skipping to change at page 3, line 51 skipping to change at page 3, line 51
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 to the well-known secure port. This method is easy to implement,
is that it is very simple to implement, with no modifications needed with no modifications needed to existing insecure implementations.
to existing insecure implementations. Thus it is the most popular The disadvantage, however, is that it doesn't scale well, with a new
approach. The disadvantage, however, is that it doesn't scale well, port required for each secure implementation. More problems with
with a new port required for each secure implementation. Hence, the this approach have been listed in [RFC2595].
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 capabilities, and start security negotiations if desired. This
method usually requires some changes in the protocol being secured method usually requires some changes 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
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 to assign a well-known
port, they settled on the following approach.
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
TCP MUST know the TCP port on which COPS/TLS is running. How this is
achieved is outside the scope of this document.
The system acting as the PEP also acts as the TLS client. It needs
to first connect to the COPS/TCP server, from where it can be
redirected to the COPS/TLS server.
During the initial negotiation with the COPS/TCP server, the Message COPS/TLS uses the Upward Negotiation method to secure COPS messages.
Integrity Object MUST be used to authenticate the validity of the
COPS messages. As specified in [RFC2748], the integrity 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 4 COPS/TLS Objects and Error codes
scope of this document.
3.2 Object Format and Error Codes This section describes the COPS objects and error codes needed to
support COPS/TLS.
This section describes the ClientSI object sent in the ClientOpen 4.1 The StartTLS ClientSI Object
message and the error codes the server returns.
3.2.1 The ClientSI object format The StartTLS ClientSI object is used by the PDP and the PEP to start
the TLS negotiation. This object can be included either in the
ClientAccept message, or a Request message. Also, the ClientType of
any message containing this ClientSI object MUST be 0.
0 1 2 3 0 1 2 3
+----------+----------+----------+----------+ +----------+----------+----------+----------+
| Length (Octets) | C-Num=9 | C-Type=1 | | Length (Octets) | C-Num=9 | C-Type=1 |
+----------+----------+----------+----------+ +----------+----------+----------+----------+
| Protocol | Flags | | //////// | Flags |
+----------+----------+----------+----------+
| : : : |
// : : : //
+----------+----------+----------+----------+
| Protocol | Flags |
+----------+----------+----------+----------+ +----------+----------+----------+----------+
Protocol:
1 = TLS
Flags: Flags:
0 = Protocol Support Optional 1 = TLS
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 Error Codes and Sub-Codes
This section adds to, and modifies, 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 Required
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
connecting to the redirected server. In the future, more sub-codes
may be added to specify additional protocols.
Error Code 17 SHOULD be used by either Client or Server 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 the server,
it SHOULD first connect to the non-secure port, and send a Client
Open message with a ClientType=0.
'Bootstrap' policies implemented on the client dictate whether
security is mandatory or optional.
If the policies specify that security is mandatory, the above-
mentioned ClientSI object MUST be included in the Client Open
message. This object MUST list one protocol as Required by setting
the corresponding flag to 1.
If the policies do not explicitly specify that a secure connection
is required, the client SHOULD include the ClientSI object, listing
protocol support as Optional.
Note that if the client's policies specifically prohibit a secure
connection, it MAY attempt to establish an insecure connection.
Based on the client's policies and the server's policy requirements
for the client, a number of usage scenarios are possible. The figure
below shows the type of connections established for the scenarios.
The sections following the figure explain 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 message with a Redirect object,
redirecting the client to the COPS/TLS secure port. Additionally,
the error object included in the ClientClose message MUST have the
error code = 12 and sub code = 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,
the error object included in the ClientClose message MUST have the
error code = 12 and sub code = 1.
If the server does not redirect the client to the secure port, it 4.2 Error Codes
MUST send a ClientClose with the error code 16.
4.3 Security Optional on Client and Mandatory on Server This section adds to the error codes described in section 2.2.8
(Error Object) of [RFC2748].
The server MUST send a ClientClose message with a Redirect object, Error Code: 16 = TLS Required
redirecting the client to the COPS/TLS secure port. Additionally,
the error object included in the ClientClose message MUST have the
error code = 12 and sub code = 1.
4.4 Security Optional on both, Client and Server This error code should be used by either PEP or PDP if they require
security but the other side doesn't support it.
The server SHOULD send a ClientClose message with a Redirect object, 5 COPS/TLS Secure Connection Initiation
redirecting the client to the COPS/TLS secure port. Additionally,
the error object included in the ClientClose message MUST have the
error code = 12 and sub code = 1.
Optionally, the server MAY proceed to establish an insecure Security negotiation may be initiated either by the PDP or the PEP.
connection over COPS/TCP. The PDP can initiate a security negotiation either via a
ClientAccept or a ClientClose message, while a PEP can initiate a
negotiation via a Request message.
4.5 Security Mandatory on Client but not supported by Server Once the TLS connection is established, all COPS data MUST be sent
as TLS "application data".
The server MUST send a ClientClose with the error code 16. 5.1 PDP Initiated Security Negotiation
The PEP initially opens a TCP connection with the PDP on the
standard COPS port and sends a ClientOpen message. This ClientOpen
message MUST have a ClientType of 0.
4.6 Security Optional on Client but not supported by Server The PDP then replies with a ClientAccept. In order to signal the PEP
to start the TLS handshake, the PDP MUST include the StartTLS
ClientSI object in the ClientAccept message.
The server SHOULD attempt to establish a non-secure connection with Note that in order to carry the StartTLS ClientSI object, the
the client. contents of the ClientAccept message defined in section 3.7 of
[RFC2748] need to change to the following:
4.7 Security Mandatory on Server but not supported by Client <Client-Accept> ::= <Common Header>
<KA Timer>
[<ACCT Timer>]
[<ClientSI>]
[<Integrity>]
If security is required by the server it MUST send a ClientClose Upon receiving the ClientAccept message with the StartTLS ClientSI
with the error code 16. object, the PEP SHOULD initiate the TLS handshake. If for any reason
the PEP cannot initiate the handshake, it MUST close the connection.
4.8 Security Optional on Server but not supported by Client The message exchange is as follows:
C: ClientOpen (ClientType = 0)
S: ClientAccept (ClientType = 0, StartTLS)
<TLS handshake>
C/S: <...further messages...>
The server it MAY attempt to establish a non-secure connection with Until the TLS handshake is complete the PEP MUST NOT send any
the client. messages other than ClientClose and KeepAlive. Upon receiving any
other message, a PDP expecting a TLS negotiation MUST issue a
ClientClose message with an error code of 16.
5 Secure Connection Initiation 5.2 PEP Initiated Security Negotiation
Once the PEP receives a redirect from the COPS/TCP server, it If a PEP wishes to use TLS on an existing non-secure COPS
initiates a connection to the PDP to the secure COPS port. When this connection, it MUST issue a Request message with a ClientType of 0.
succeeds, the PEP system sends the TLS ClientHello to begin the TLS The StartTLS ClientSI object MUST be included in the request.
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 In response, the PDP SHOULD send a Decision message containing the
mechanism to identify authorized PDPs. This requirement provides a appropriate Command-Code (1 = Install/Accept, 2 = Remove/Reject) in
level of assurance that the policy arriving at the PEP is actually the Decision Flags object.
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 If the request is accepted, the PEP MUST start the TLS handshake.
control mechanism permitting them to restrict their services to After the TLS handshake is complete, the PDP MUST synchronize state
authorized PEP systems only. However, implementations MAY choose not with the PEP.
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. The message exchange is as follows:
<...existing COPS/TCP connection...>
C: Request (ClientType = 0, StartTLS)
S: Decision (ClientType = 0, Install)
<TLS handshake>
S: Synchronize
If the PEP's TLS request is rejected by the PDP, the PEP MAY choose
to continue using the non-secure connection. Else, it MUST close the
connection by sending a ClientClose message with an error code of
16.
6 Connection Closure 6 Connection Closure
TLS provides facilities to securely close its connections. Reception TLS provides facilities to securely close its connections. Reception
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
skipping to change at page 8, line 52 skipping to change at page 6, line 30
capability. capability.
A connection closed without first sending a closure alert is known A connection closed without first sending a closure alert is known
as a "premature close". Note that a premature close does not call as a "premature close". Note that a premature close does not call
into 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 indicates that subsequent data might have been truncated. Because
TLS is oblivious to COPS message boundaries, it is necessary to TLS is oblivious to COPS message boundaries, it is necessary to
examine the COPS data itself (specifically the Message header) to examine the COPS data itself (specifically the Message header) to
determine 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 PEPs unprepared to receive any more data MAY choose not to wait for
for the PDP system's closure alert and simply close the connection, the PDP system's closure alert and simply close the connection, thus
thus generating an incomplete close on the PDP side. 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 PDPs to recover gracefully. In particular, PDPs SHOULD be prepared
to 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 close the connection after sending the closure alert, thus
generating 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- 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 Open message. The first data a TLS server (and hence a COPS/TLS PDP)
server) expects to receive is the ClientHello. Consequently, expects to receive is the ClientHello. Consequently, COPS/TLS runs
COPS/TLS runs over a separate port in order to distinguish it from over a separate port in order to distinguish it from COPS alone.
COPS alone. When COPS/TLS runs over a TCP/IP connection, the TCP When COPS/TLS runs over a TCP/IP connection, the TCP port is any
port is any non-well-known port of the PDP's choice. This port MUST non-well-known port of the PDP's choice. This port MUST be
be communicated to the COPS/TCP server running on the well-known communicated to the COPS/TCP PDP running on the well-known COPS TCP
COPS TCP port. The PEP may use any TCP port. This does not preclude port. The PEP may use any TCP port. This does not preclude COPS/TLS
COPS/TLS from running over another transport. TLS only presumes a from running over another transport. TLS only presumes a reliable
reliable connection-oriented data stream. connection-oriented data stream.
8 Endpoint Identification and Access Control 8 Endpoint Identification and Access Control
All PEP implementations of COPS/TLS MUST support an access control
mechanism to identify authorized PDPs. This requirement provides a
level of assurance that the policy arriving at the PEP is actually
valid. PEP 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.
Implementations of COPS/TLS MUST use X.509 v3 certificates Implementations of COPS/TLS MUST use X.509 v3 certificates
conforming to [RFC2459] to identify PDP and PEP systems. COPS/TLS conforming to [RFC3280] to identify PDP and PEP systems. COPS/TLS
systems MUST perform certificate verification processing conforming systems MUST perform certificate verification processing conforming
to [RFC2459]. In case the Certificate Authority cannot be accessed, to [RFC3280].
the COPS/TLS systems MAY use a Web of Trust to verify the identity,
or the communication MAY revert to insecure.
If a subjectAltName extension of type dNSName or iPAddress is If a subjectAltName extension of type dNSName or iPAddress is
present in the PDP's certificate, it MUST be used as the PDP present in the PDP's certificate, it MUST be used as the PDP
identity. Otherwise, the most specific Common Name field in the identity. If both types are present, dNSName SHOULD be used as the
Subject field of the certificate MUST be used. 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 Matching is performed using the matching rules specified by
[RFC2459]. If more than one identity of a given type is present in [RFC3280]. 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 the certificate (e.g. more than one dNSName name in the
of the set is considered acceptable), the COPS system uses the first subjectAltName certificate extension), a match in any one of the
name to match, except as noted below in the IP address checking provided identities is acceptable. Generally, the COPS system uses
requirements. Names may contain the wildcard character * which is the first name for matching, except as noted below in the IP
considered to match any single domain name component or component address checking requirements.
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 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 that identifies PDPs that the PEP is bootstrap policy information that identifies PDPs that the PEP is
authorized to connect to. This policy provides the PEP with the authorized to connect to. This policy provides the PEP with the
hostname or IP address of the PDP. How this bootstrap policy hostname or IP address of the PDP. How this bootstrap policy
information arrives at the PEP is outside the scope of this information arrives at the PEP is outside the scope of this
document. However, all PEP implementations MUST provide a mechanism document. However, all PEP implementations MUST provide a mechanism
to securely deliver or configure the bootstrap policy. 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 All PEP implementations MUST be able to securely acquire the signing
certificates of authorized Certificate Authorities that issue PDP certificates of authorized Certificate Authorities that issue PDP
certificates. Also, the PEPs MUST support a mechanism to securely certificates. Also, the PEPs MUST support a mechanism to securely
acquire an access control list or filter identifying the CA's set of acquire an access control list or filter identifying the CA's set of
authorized PDPs. 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 CAs and access control those on mobile platforms, MAY use different CAs and access control
lists in each domain. lists in each domain.
skipping to change at page 11, line 16 skipping to change at page 9, line 8
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 requirement for PEP systems to register with a certificate
authority, and COPS over TLS uses one-way authentication, of the PDP authority, and COPS over TLS uses one-way authentication, of the PDP
to the PEP. 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 [RFC2459]. In this case, COPS over TLS uses two-way the sense of [RFC3280]. In this case, COPS over TLS uses two-way
authentication, and the PDP MUST perform the same identity checks authentication, and the PDP MUST perform the same identity checks
for 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 MUST have a mechanism to securely acquire the signing certificates
of the Certificate Authorities issuing certificates to any of the of the Certificate Authorities issuing certificates to any of the
PEPs they support. PEPs they support.
9 Other Considerations 9 Backward Compatibility
9.1 Backward Compatibility The PEP and PDP SHOULD be backward compatible with peers that have
not been modified to support COPS/TLS. They SHOULD handle errors
generated in response to the StartTLS ClientSI object.
The client and server SHOULD be backward compatible with peers that In case a PEP does not start the TLS handshake upon receiving the
have not been modified to support COPS/TLS. StartTLS ClientSI object, the PDP MUST close the connection.
A client SHOULD be able to handle errors generated by a COPS/TCP 10 IANA Considerations
server which does not understand the ClientSI object mentioned
above. Similarly, if a COPS/TCP server receives a ClientOpen for
Client type=0, which does not contain the ClientSI object, it SHOULD
assume that the client wishes to open a non-secure connection and
proceed accordingly.
9.2 IANA Considerations The IANA shall add the following Error-Code to the cops-parameters
document:
This draft defines some new error codes and sub codes which require Error-Code: 16
IANA approval. Section 3.2.2 has more details on these codes. Description: TLS Required
10 Security Considerations 11 Security Considerations
This entire document concerns security. 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.
11 Acknowledgements 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 This document freely plagiarizes and adapts Eric Rescorla's similar
document [RFC2818] that specifies how HTTP runs over TLS. document [RFC2818] that specifies how HTTP runs over TLS.
Discussions with David Durham, Scott Hahn and Ylian Sainte-Hillaire Discussions with David Durham, Scott Hahn and Ylian Sainte-Hillaire
also lead to improvements in this document. also lead to improvements in this document.
The authors wish to thank Uri Blumenthal for doing a thorough The authors wish to thank Uri Blumenthal for doing a thorough
security review of the document. security review of the document.
12 References 13 References
12.1 Normative References 13.1 Normative References
[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.
[RFC2748] Durham, D., Boyle, J., Cohen, R., Herzog, R., Rajan, [RFC2748] Durham, D., Boyle, J., Cohen, R., Herzog, R., Rajan,
R., Sastry, A., "The COPS (Common Open Policy Service) Protocol", R., Sastry, A., "The COPS (Common Open Policy Service) Protocol",
RFC 2748, January 2000. RFC 2748, January 2000.
[RFC2459] Housley, R., Ford, W., Polk, W., Solo, D., "Internet [RFC3280] Housley, R., Ford, W., Polk, W., Solo, D., "Internet
Public Key Infrastructure: Part I: X.509 Certificate and CRL X.509 Public Key Infrastructure Certificate and Certificate
Profile", RFC 2459, January 1999. Revocation List (CRL) Profile ", RFC 3280, April 2002.
[RFC2246] Dierks, T., Allen, C., "The TLS Protocol", RFC 2246, [RFC2246] Dierks, T., Allen, C., "The TLS Protocol", RFC 2246,
January 1999. January 1999.
12.2 Informative References 13.2 Informative References
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC2818, May 2000.
13 Author Addresses [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 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[at]intel.com jesse.walker[at]intel.com
Amol Kulkarni Amol Kulkarni
Intel Corporation Intel Corporation
JF3-206 JF3-206
2111 N.E. 25th Avenue 2111 N.E. 25th Avenue
Hillsboro, OR 97214 Hillsboro, OR 97214
USA USA
amol.kulkarni[at]intel.com 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.
 End of changes. 

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