draft-ietf-rap-cops-tls-05.txt   draft-ietf-rap-cops-tls-06.txt 
Internet Draft Jesse Walker Internet Draft Jesse Walker
Expiration: July 2003 Amol Kulkarni Expiration: November 2003 Amol Kulkarni
File: draft-ietf-rap-cops-tls-05.txt Intel Corp. File: draft-ietf-rap-cops-tls-06.txt Intel Corp.
COPS Over TLS COPS Over TLS
Last Updated: February 6, 2003 Last Updated: May 23, 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 months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in as reference material or to cite them other than as "work in
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in [RFC-2119]. this document are to be interpreted as described in [RFC2119].
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 Mandatory on both, Client and Server.................6
4.2 Security Required By Client and Optional on Server............5 4.2 Security Mandatory on Client and Optional on Server...........6
4.3 Security Optional on Client and Required on Server............6 4.3 Security Optional on Client and Mandatory on Server...........6
4.4 Security Optional on Client and Server........................6 4.4 Security Optional on both, Client and Server..................6
4.5 Security Supported by Client but not by Server................6 4.5 Security Mandatory on Client but not supported by Server......6
4.6 Security supported by Server but not by Client................6 4.6 Security Optional on Client but not supported by Server.......6
4.7 Security not Supported by either Client or Server.............6 4.7 Security Mandatory on Server but not supported by Client......6
5 Secure Connection Initiation....................................6 4.8 Security Optional on Server but not supported by Client.......6
6 Connection Closure..............................................7 5 Secure Connection Initiation...................................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.........................................8
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.................................................9
8.2 PEP Identity.................................................9 8.2 PEP Identity................................................10
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.1 Normative References........................................10 12.1 Normative References........................................10
12.2 Informative References......................................10 12.2 Informative References......................................11
13 Authors' Addresses...........................................11 13 Author Addresses..............................................11
1 Introduction 1 Introduction
COPS [COPS] was designed to distribute clear-text policy information COPS [RFC2748] was designed to distribute clear-text policy
from a centralized Policy Decision Point (PDP) to a set of Policy information from a centralized Policy Decision Point (PDP) to a set
Enforcement Points (PEP) in the Internet. COPS provides its own of Policy Enforcement Points (PEP) in the Internet. COPS provides
security mechanisms to protect the per-hop integrity of the deployed its own security mechanisms to protect the per-hop integrity of the
policy. However, the use of COPS for sensitive applications such as deployed policy. However, the use of COPS for sensitive applications
some types of security policy distribution requires additional such as some types of security policy distribution requires
security measures, such as data privacy. This is because some additional security measures, such as data privacy. This is because
organizations find it necessary to hide some or all of their some organizations find it necessary to hide some or all of their
security policies, e.g., because policy distribution to devices such security policies, e.g., because policy distribution to devices such
as mobile platforms can cross domain boundaries. as mobile platforms can cross domain boundaries.
TLS [TLS] was designed to provide channel-oriented security. TLS TLS [RFC2246] 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
skipping to change at page 4, line 22 skipping to change at page 4, line 22
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 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 to first connect to the COPS/TCP server, from where it can be
redirected to the COPS/TLS server. redirected to the COPS/TLS server.
During the initial negotiation with the COPS/TCP server, the Message
Integrity Object MUST be used to authenticate the validity of the
COPS messages. The use of the integrity object is described in
[RFC2748]. How the keys indicated by the Integrity Object are shared
between the Client and Server is outside the scope of this document.
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
+----------+----------+----------+----------+ +----------+----------+----------+----------+
| Length (Octets) | C-Num=9 | C-Type=2 | | Length (Octets) | C-Num=9 | C-Type=2 |
skipping to change at page 4, line 47 skipping to change at page 5, line 4
+----------+----------+----------+----------+ +----------+----------+----------+----------+
| Protocol | Flags | | Protocol | Flags |
+----------+----------+----------+----------+ +----------+----------+----------+----------+
Protocol: Protocol:
1 = TLS 1 = TLS
Flags: Flags:
0 = Protocol Support Optional 0 = Protocol Support Optional
1 = Protocol Support Required 1 = Protocol Support Required
This ClientSI object MUST be included with the ClientOpen message This ClientSI object MUST be included with the ClientOpen message
(Client Type = 0) when the client supports security. For each (Client Type = 0) when the client supports security. For each
supported protocol, there MUST be a 32 bit Protocol+Flags pair supported protocol, there MUST be a 32 bit Protocol+Flags pair
appended to the object. At present, only one protocol (TLS) is appended to the object. At present, only one protocol (TLS) is
described. However, the ClientSI object definition is general enough described. However, the ClientSI object definition is general enough
to allow addition of new protocols in the future. to allow addition of new protocols in the future.
If multiple protocols are supported by the client, it MUST ensure If multiple protocols are supported by the client, it MUST ensure
that no more than one has the 'Protocol Support Required' flag set. that no more than one has the 'Protocol Support Required' flag set.
Note that it is also valid to mark all protocols as optional. Note that it is also valid to mark all protocols as optional.
3.2.2 Error Codes and Sub-Codes 3.2.2 Error Codes and Sub-Codes
This section adds to, and modifies, the error codes described in This section adds to, and modifies, the error codes described in
section 2.2.8 (Error Object) of [COPS]. section 2.2.8 (Error Object) of [RFC2748].
Error Code: 12 = Redirect to Preferred Server: Error Code: 12 = Redirect to Preferred Server:
Sub-code: Sub-code:
0 = Regular redirect (no security necessary) 0 = Regular redirect (no security necessary)
1 = Use TLS 1 = Use TLS
Error Code: 16 = Security Failure Error Code: 16 = Security Failure
17 = Security Required 17 = Security Required
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 SHOULD be used by either Client or Server if they
security but the other side doesn't support it. require 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, 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 it SHOULD first connect to the non-secure port, and send a Client
Open message with a ClientType=0. Included in this message, MUST be Open message with a ClientType=0.
a ClientSI object, which lists the security capabilities of the
client.
The following scenarios occur:
4.1 Security Required By Client and Server The policies implemented on the client dictate whether security is
mandatory or optional.
If the server's internal policies allow the client to connect, the If the policies specify that security is mandatory, the above-
server MUST send a ClientClose message with a Redirect object, 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 a non-secure connection.
Based on the client's policies and the server's policy requirements
for the client, the following scenarios occur:
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, redirecting the client to the COPS/TLS secure port. Additionally,
the error object included in the ClientClose message MUST have the the error object included in the ClientClose message MUST have the
error 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 4.2 Security Mandatory on Client and Optional on Server
connect, the server MUST send a ClientClose with an appropriate
error code.
4.2 Security Required By Client and Optional on Server
If the server's internal policies allow the client to connect The server SHOULD send a ClientClose message with a Redirect object,
securely, the server MUST send a ClientClose message with a Redirect redirecting the client to the COPS/TLS secure port. Additionally,
object, redirecting the client to the COPS/TLS secure port. the error object included in the ClientClose message MUST have the
Additionally, the error object included in the ClientClose message 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 does not redirect the client to the secure port, it
securely, the server MUST send a ClientClose with error code 16 or MUST send a ClientClose with the error code 16.
another more appropriate error code.
4.3 Security Optional on Client and Required on Server 4.3 Security Optional on Client and Mandatory on Server
Depending upon its internal policies, the server MAY send a The server MUST send a ClientClose message with a Redirect object,
ClientClose message with a Redirect object, redirecting the client redirecting the client to the COPS/TLS secure port. Additionally,
to the COPS/TLS secure port. the error object included in the ClientClose message MUST have the
error code = 12 and sub code = 1.
4.4 Security Optional on Client and Server 4.4 Security Optional on both, Client and Server
Depending upon its internal policies, the server MAY send a The server SHOULD send a ClientClose message with a Redirect object,
ClientClose message with a Redirect object, redirecting the client redirecting the client to the COPS/TLS secure port. Additionally,
to the COPS/TLS secure port. 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 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 Mandatory on Client but not supported by Server
If the Client's capabilities specify that security is optional, the The server MUST send a ClientClose with the error code 16.
server MAY proceed to establish an insecure connection. Otherwise,
it MUST send a ClientClose with the error code 16.
4.6 Security supported by Server but not by Client 4.6 Security Optional on Client but not supported by Server
The server SHOULD attempt to establish a non-secure connection with
the client.
4.7 Security Mandatory on Server but not supported by Client
If security is required by the server it MUST send a ClientClose If security is required by the server it MUST send a ClientClose
with the error code 16. If security is optional on the server, it with the error code 16.
MAY establish an insecure connection with the client.
4.7 Security not Supported by either Client or Server 4.8 Security Optional on Server but not supported by Client
This is the regular COPS/TCP case as described in [COPS]. In this The server it MAY attempt to establish a non-secure connection with
case, only an insecure connection is possible. the client.
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 handshake. When the TLS handshake completes, the PEP MAY initiate
the first COPS message. All COPS data MUST be sent as TLS the first COPS message. All COPS data MUST be sent as TLS
"application data". Normal COPS behavior follows. "application data". Normal COPS behavior follows.
skipping to change at page 8, line 33 skipping to change at page 8, line 48
COPS alone. When COPS/TLS runs over a TCP/IP connection, the TCP COPS alone. When COPS/TLS runs over a TCP/IP connection, the TCP
port is any non-well-known port of the PDP's choice. This port MUST port is any non-well-known port of the PDP's choice. This port MUST
be communicated to the COPS/TCP server running on the well-known be communicated to the COPS/TCP server running on the well-known
COPS TCP port. The PEP may use any TCP port. This does not preclude COPS TCP port. The PEP may use any TCP port. This does not preclude
COPS/TLS from running over another transport. TLS only presumes a COPS/TLS from running over another transport. TLS only presumes a
reliable connection-oriented 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 Implementations of COPS/TLS MUST use X.509 v3 certificates
conforming to [PKIX] to identify PDP and PEP systems. COPS/TLS conforming to [RFC2459] to identify PDP and PEP systems. COPS/TLS
systems MUST perform certificate verification processing conforming systems MUST perform certificate verification processing conforming
to [PKIX]. to [RFC2459]. In case the Certificate Authority cannot be accessed,
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, that MUST be used as the PDP present in the PDP's certificate, that MUST be used as the PDP
identity. Otherwise, the most specific Common Name field in the identity. Otherwise, the most specific Common Name field in the
Subject field 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
If more than one identity of a given type is present in the [RFC2459]. If more than one identity of a given type is present in
certificate (e.g. more than one dNSName name, a match in any one of the certificate (e.g. more than one dNSName name, a match in any one
the set is considered acceptable.), the COPS system uses the first of the set is considered acceptable.), the COPS system uses the
name to match, except as noted below in the IP address checking first name to match, except as noted below in the IP address
requirements. Names may contain the wildcard character * which is checking requirements. Names may contain the wildcard character *
considered to match any single domain name component or component which is considered to match any single domain name component or
fragment. For example, *.a.com matches foo.a.com but not component fragment. For example, *.a.com matches foo.a.com but not
bar.foo.a.com. f*.com matches foo.com but not foo.bar.com. 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
skipping to change at page 9, line 52 skipping to change at page 10, line 17
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 [PKIX]. In this case, COPS over TLS uses two-way the sense of [RFC2459]. 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 Other Considerations
skipping to change at page 10, line 33 skipping to change at page 10, line 49
This draft defines some new error codes and sub codes which require This draft defines some new error codes and sub codes which require
IANA approval. Section 3.2.2 has more details on these codes. IANA approval. Section 3.2.2 has more details on these codes.
10 Security Considerations 10 Security Considerations
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.
with David Durham, Scott Hahn and Ylian Sainte-Hillaire also lead to Discussions with David Durham, Scott Hahn and Ylian Sainte-Hillaire
improvements in this document. also lead to improvements in this document.
12 References 12 References
12.1 Normative References 12.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.
[COPS] Durham, D., Boyle, J., Cohen, R., Herzog, R., Rajan, R., [RFC2748] Durham, D., Boyle, J., Cohen, R., Herzog, R., Rajan,
Sastry, A., "The COPS (Common Open Policy Service) Protocol", RFC R., Sastry, A., "The COPS (Common Open Policy Service) Protocol",
2748, January 200. RFC 2748, January 200.
[PKIX] Housley, R., Ford, W., Polk, W., Solo, D., "Internet [RFC2459] Housley, R., Ford, W., Polk, W., Solo, D., "Internet
Public Key Infrastructure: Part I: X.509 Certificate and CRL Public Key Infrastructure: Part I: X.509 Certificate and CRL
Profile", RFC 2459, January 1999. Profile", RFC 2459, January 1999.
[TLS] Dierks, T., Allen, C., "The TLS Protocol", RFC2246, January [RFC2246] Dierks, T., Allen, C., "The TLS Protocol", RFC 2246,
1999. January 1999.
12.2 Informative References 12.2 Informative References
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC2818, May 2000.
13 Authors' Addresses 13 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@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@intel.com amol.kulkarni[at]intel.com
 End of changes. 

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