draft-ietf-rap-cops-tls-01.txt   draft-ietf-rap-cops-tls-02.txt 
Internet Draft Jesse Walker Internet Draft Jesse Walker
Expiration: March 2002 Amol Kulkarni Expiration: April 2002 Amol Kulkarni
File: draft-ietf-rap-cops-tls-01.txt Intel Corp. File: draft-ietf-rap-cops-tls-02.txt Intel Corp.
COPS Over TLS COPS Over TLS
Last Updated: September 7, 2001 Last Updated: October 18, 2001
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 3, line 53 skipping to change at page 3, line 53
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 COPS/TLS
connections to systems not authorized as PDPs by the access control connections to systems not authorized as PDPs by the access control
mechanism. 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. Implementations MUST NOT require the use authorized PEP systems only. However, implementations MUST NOT
of an access control mechanism at the PDP, however, as organizations require the use of an access control mechanism at the PDP, as
might not consider as sensitive the types of policy being deployed, organizations might not consider the types of policy being deployed
and therefore do not need to incur the expense of managing as sensitive, and therefore do not need to incur the expense of
credentials for the PEP systems. However, if access controls are managing credentials for the PEP systems. If access controls are
used, the PDP implementation MUST terminate COPS/TLS connections from used, however, the PDP implementation MUST terminate COPS/TLS
unauthorized PEP systems and log an error if an auditable logging connections from unauthorized PEP systems and log an error if an
mechanism is present. auditable logging mechanism is present.
2.2. Connection Closure 2.2. 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 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. TLS allows implementations to provided they send their own first. A connection closed in this way
is known as an "incomplete close". TLS allows implementations to
reuse the session in this case, but COPS/TLS makes no use of this reuse the session in this case, but COPS/TLS makes no use of this
capability. capability.
Note that a premature close does not call into question the security A connection closed without first sending a closure alert is known as
of the data already received, but simply indicates that subsequent a "premature close". Note that a premature close does not call into
data might have been truncated. Because TLS is oblivious to COPS question the security of the data already received, but simply
message boundaries, it is necessary to examine the COPS data itself indicates that subsequent data might have been truncated. Because TLS
(specifically the Message header) to determine whether truncation is oblivious to COPS message boundaries, it is necessary to examine
occurred. the COPS data itself (specifically the Message header) to determine
whether truncation occurred.
2.2.1. PEP System Behavior 2.2.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
skipping to change at page 5, line 34 skipping to change at page 5, line 36
of the certificate MUST be used. 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 bar.com. bar.foo.a.com. f*.com matches foo.com but not foo.bar.com.
3.1. PDP Identity 3.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 support
skipping to change at page 7, line 5 skipping to change at page 7, line 5
COPS over TLS uses a separate TCP port from COPS. IANA should assign COPS over TLS uses a separate TCP port from COPS. IANA should assign
the value TBD to this port. the value TBD to this port.
5. Security Considerations 5. Security Considerations
This entire document concerns security. This entire document concerns security.
6. Acknowledgements 6. Acknowledgements
This document freely plagiarizes and adapts Eric Rescorla's similar This document freely plagiarizes and adapts Eric Rescorla's similar
document draft-ietf-tls-http-xx.txt that specifies how HTTP runs over document RFC2818 that specifies how HTTP runs over TLS. Discussions
TLS. Discussions with David Durham and Ylian Sainte-Hillaire also with David Durham and Ylian Sainte-Hillaire also lead to improvements
lead to improvements in this document. in this document.
7. References 7. References
[COPS] Durham, D., Boyle, J., Cohen, R., Herzog, R., Rajan, R., [COPS] Durham, D., Boyle, J., Cohen, R., Herzog, R., Rajan, R.,
Sastry, A., "The COPS (Common Open Policy Service) Protocol", RFC Sastry, A., "The COPS (Common Open Policy Service) Protocol", RFC
2748, January 200. 2748, January 200.
[PKIX] Housley, R., Ford, W., Polk, W., Solo, D., "Internet Public [PKIX] Housley, R., Ford, W., Polk, W., Solo, D., "Internet Public
Key Infrastructure: Part I: X.509 Certificate and CRL Profile", Key Infrastructure: Part I: X.509 Certificate and CRL Profile",
RFC 2459, January 1999. 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.
[TLS] Dierks, T., Allen, C., "The TLS Protocol", RFC2246, January [TLS] Dierks, T., Allen, C., "The TLS Protocol", RFC2246, January
1999. 1999.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC2818, May 2000.
8. Author Addresses 8. 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@intel.com
 End of changes. 

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